On the other hand, having to learn 17 different DSLs (from crontab to AWS policy) isn't that far fetched from reality and it puts a lot of burden on people. Every product has a specialized DSL with unique restrictions and just never general enough. Stack Overflow is overflowing with such questions. People are thoroughly confused by "127.0.0.1:9090" vs. "127.0.0.1:9090:9090" or "9090:9090" or "0.0.0.0:9090"... docker network configs. Good lord, it is terrible, sorry, not to shed bad light on Docker; but to exemplify that this is a common thing.
One of the worst experiences in programming is writing CI/CD pipelines. One wonders why...
In most cases (including your examples) it's not really the DSL that is the problem, but the domain specific problem. Portmapping in docker isn't uniform because there are many options available that are all equally useful and up to the user to select. Crontabs have to describe time periodic values, and pretty much any other application that tries to solve a specific problem will not be all that generic (since they are not meant to solve all problems generically at once).
Like I wrote in my comment, how much specific things you need to know will depend on how many specific tasks you perform. If you specialise in nothing, everything will have depths unknown. It will also dilute attention/focus which in turn means you'll never be able to fully understand a specific domain or application. This was reflected in https://news.ycombinator.com/item?id=33056052 where the path it took for many developers and engineers in general to find a fitting solution is unknown to newcomers and also simply not taught in favour of delivering "reviewables" in hopes of a positive review (https://news.ycombinator.com/item?id=33056705) .
Sidenote: mapping ports used to be rather verbose, you'd have to include the address family, the address and the port, on both sides of the mapping. That's 6 elements (excluding separators). So most applications including docker made various parts optional. You can map two ports to any interface, or opt to specify one interface but not the other one etc. A novice user of a new application might be best served by not using any shorthand forms and only using the fully qualified names everywhere. By spelling out every option explicitly (including optional values) there is no more guessing what may or may not have been configured.
One of the worst experiences in programming is writing CI/CD pipelines. One wonders why...