Why?

Look at your home

$ find ~ -mindepth 1 -maxdepth 1 -type f -printf '%fn' -or -type d -printf '%f/n'
.alsoftrc
.android/
.ansible/
.aqbanking/
.audacity-data/
.bashrc
.cache/
.choosenim/
.code-d/
.config/
config/
.cpan/
data/
Desktop/
Downloads/
Documents/
.eclipse/
.elementary/
.emacs.d/
.emulator_console_auth_token
.flutter
.flutter_tool_state
.gem/
.ghc/
.ghidra/
.gnome/
.gnupg/
.godot/
.gore/
.gradle/
.gsutil/
.guestfish
.heekscad
.helioslauncher/
HomeBank-20210521.bak
HomeBank-20210607.bak
HomeBank-20210611.bak
.hushlogin
.idapro/
.ivy2/
.java/
javasharedresources/
.kb/
.kube/
.lldb/
.local/
.lunarclient/
.lyxauth
.m2/
macOS.vdi
.mcfly/
.metals/
.minecraft/
.mono/
.mozilla
.mputils/
.mume/
Music/
.omnisharp/
.ort/
.osc_cookiejar
.pack/
.paradoxlauncher/
.parsec/
Pictures/
.pki/
.pm2/
.profile
.pythonhist
.sbt/
.scim/
.ssh/
.steam/
.steampath
.steampid
.step/
.subversion/
.swt/
.tooling/
'Universe Sandbox'/
Videos/
.vscode/
.w3m/
.wine/
.xinitrc
.yarnrc
.zcompdump
.zoom/
.zshenv

What if your house was clean and tidy?

$ find ~ -mindepth 1 -maxdepth 1 -type f -printf '%fn' -or -type d -printf '%f/n'
.bashrc
.cache/
.config/
Desktop/
Downloads/
Documents/
.local/
Music/
Pictures/
.profile
Videos/

End users of your application (and hopefully yourself, as well) want a clean home directory. Instead of having files like ~/.gitconfig scattered chaotically in the home folder, it would be better for them to reside in a dedicated configuration directory.

I like how Filip from 0x46.net explained the issue from the perspective of a user:

Succinctly, following the spec means (by the very least) your application files are nearly categorized in subdirectories of the home folder. For instance, locations of cache files default to ~/.cache while locations of config files default to ~/.config, etc.

Benefits

If you aren’t already sold on a clean home directory, there are additional benefits.

• Easier to create backups

Since several directories (ex. ~/.config, by default) represent a discrete class of application files, it is much easier to make rules for a specific category of files during backup.

• Easier to share configuration settings

Since all settings are in a single directory, they can more easily be shared across computer systems.

• Easier to isolate application state

Since all data specific to a single machine is in a single directory, you can easily avoid sharing it between systems when sharing data or backups.

• Easier to temporarily ignore the config

Not all applications have a --no-config option (especially GUI applications), and those that do have a --config option do not always work when using /dev/null as a file, shell process substitution, or a simple empty file. It is easiest to set XDG_CONFIG_HOME=/tmp/dir.

• Decreased reliance on hard-coded paths (flexibility + composability)

As a more concrete example, imagine that /etc did not exist – configuration would be chaotically scattered about in a way similar to how $HOME exists today. But, because we have /etc specifically designated as a directory for config files (along with other directories) by the File Hierarchy Standard, it is significantly easier to locate, edit, and backup system files across machines. Those ergonomics should not just exist for system-level files, but for the user-level as well.

Thus, I implore, I beg all you application developers to implement the XDG Base Directory Specification.

How?

First, categorize the files that your program needs to write into four categories:

1. Configuration

Configuration files that affect the behavior of an program. Even if the configuration file is not meant to be human-editable, it likely belongs here.

2. Data

General files and data that is inherently portable across computers. Examples include fonts, files downloaded from the internet, and desktop entries.

3. State

Files that hold the state of the application. Th