Unfortunately, we cannot make this change even for, or before, Swift 5. There are plenty of manually-written implementations out there (not to mention actual Encoder implementations), and we are past the point of being willing to make source-breaking changes to APIs without significant evidence of harm.
Normally, if we were to make changes, we would deprecate old API and introduce new API; however, because of the details of try and throwing in Swift, it is not possible to overload methods based on whether they throw, so we couldn't have a throwing version and a non-throwing version simultaneously.
The API contract requires you to support all kinds of containers; if you cannot support them (even by accepting contents through them and, say, translating values into dictionaries), then you're not meeting the API contract, and it's likely that your format is not a good match for the Codable, unfortunately.
Yes — to clarify, I meant that requesting containers can (and should) be relatively cheap.