The ~/.whatevertheyfeellike is an antipattern (that is annoying) but the others are well defined in the xdg_desktop spec[0].
Personally I appreciate knowing where the config/cache for each application is. (Though it does annoy me when programs don't follow this as in your third example)
It usually doesn't, and it's mostly a good standards recommendation that even the most GPL of GPL codebases doesn't always follow (looking at you, emacs).
Software specifications are usually adopted by convention and implemented to minimize surprise and make things interoperable. They are not authorities and cannot make anyone do anything. One of the most common software failure modes is to implement a specification too tightly or in a way that nobody wants although the reverse is a problem as well.
They don't. XDG specifications are recommendations. Their only power is that your software will integrate poorly with other software (specially desktop software) if you ignore their guidelines.
I would disagree, files that the user cannot edit or should not edit should not be going into their home directory. Things like cache files should go into a system wide cache directory instead.
Isn't that very anti-linux though, to have a directory owned by root but populated with subfolders owned by other users? /home is the only exception I can think of that does this.
If I uninstall ssh I still want to have have my authorized hosts. If I uninstall some firefox version firefox I want to keep my profiles. XDG defines a thumbnailing hierarchy followed by multiple libraries, uninstalling any of those shouldn't clear thumbnail caches.
Persistent user-specific state needs to live in a persistent user-specific location. You could choose not to use the concept of a home directory, but you would be doomed to reinvent it.
The fact that nobody does that is pretty much a consequence of the difficulty of coordinating multiple projects that do not have a common authority, not because it is a bad idea.
I agree cache file should not go into their home directory, however I don't agree they aren't user data and that they would be part of the software installation.
That is not part of the software itself so it is still correctly installed/uninstalled.
Now I believe all software should have a manpage, dialog and a cli argument that describes where all the files[1] generated by default go but that is another subject.
MSIX packaged apps do support this, Windows redirects file writes outside of home dirs and other user locations to a package-specific directory that's overlayed back onto the system so the app thinks it's writing to wherever, but it's actually a package-private location.
> you can query any file to see which package owns it
Presumably you mean something like using dpkg/apt for a Debian-style system?
I think that only works if a file is actually installed from within the framework. As soon as you've installed a file via npm, flatpak, pip, snap, specialist plug-in, standalone binary, that ancient program you had to install by hand, or one of the other squillions of ways of getting an executable program, you're out of luck and have to figure it out manually.
Ok, I see what you're saying here, still, Linux's way is better, I'd rather have my system cluttered with useless files of deleted programs than be exploited because of something that was solved decades ago.