I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?
Easier to version your configs if they're all in one place. Easier to find a config file, less guess-work. Generally helps keep the home directory tidy of cruft. Not a huge deal, obviously, but programs should be well-behaved programs.
The whole point of .cache is that it's supposed to be that one folder that you know you shouldn't back up. As opposed to a dozen different app-specific ones that we have today.
Yes, it's a great idea in principle -- and would be even better if its location were configurable, per the XDG spec.
My comment wasn't meant as a criticism of the basic idea of a standard directory scheme; it was a reply to someone asking why anyone would ever care about files you can't see.
Point of order: Some of us really want ~/.local backed up or otherwise persisted; I've got the equivalent of a second /usr in there, and I only don't worry about "backing it up" because ~/.local/etc is in version control, and the rest is installed by my setup scripts.
My partner has to manage having a 500MB quota on their home directory at work. A couple of times a month something decides to dump 300+ MB of data in there and break everything.
Apps use dotfiles or dotdirs for caching data. Think browser caches. That's the point of the standard... All the non essential caching data lives in one place and so is easy to prune when needed.
Preferences files tend to be pretty small; I'd be rather surprised even if a 128MB thumb drive couldn't store them all. The bulk of the space will almost certainly be consumed by other things.
You cannot and should never assume that dotfiles are just preference files. They might be directories, and those directories might be chock full of big files — or worse, temp files that should really be in /tmp.