ATS is configurable to allow arbitrary loads, but specify which domains you wish to keep secure. The author of the above post failed to document or mention that. Most developers will have known domains that they wish to keep secure, and there are options available to do that.
Correct but most non toy apps don't hard code URL's even for their own services. If my service is getting ddosed/updated I should be able to push a configuration change out to apps and have them request another arbitrary URL. I might not know ahead of time what that URL will be, and ATS should be enforced on those URLs.
Well that's just silly. There are plenty of high profiles apps out there with many users who have a set of known domains that their app will need to connect to. As an example, Facebook, will never push a config update that points their app do a domain other than Facebook. Most big apps will likely have backend mitigation for problems like DDoS. You're right that most apps don't hardcode URLs, but most configs also don't update domains to something completely unexpected on a regular basis. Also, even if you enable ATS on specific domains and you need to point your config elsewhere, following Google's instruction, that will mean your new endpoint no longer enforces ATS, which is still better than having disabled ATS for every URL in your app for all users from the start.