I do the same thing across my (meagre) docker infrastructure, and the reason is simple: If the code isn't running, I know I can just do a disk backup of the target system. Docker is also helpful because I can know beyond a shadow of a doubt that the things that can change are on the mounted volumes and it is not possible for something important that I should be backing up to be hiding out in some directory I didn't realize it was using.
So even in my modest environment, you're asking me to write special support for backing up a MySQL DB, the SQLite DB used by vaultwarden, and I don't even know what that mess in the Plex directory is. Or I can just write the same "shut it down, back it up, bring it back up" for every service, regardless of what database it currently has, what it may change to in the future, or what other databases some other service might decide it wants. It's an easy choice.
You hit the nail on the head and that is exactly why I do it that way. I don't have to worry about all the different ways different databases need to be backed up if they are running and the outage window is measured in seconds in the middle of the night.
So even in my modest environment, you're asking me to write special support for backing up a MySQL DB, the SQLite DB used by vaultwarden, and I don't even know what that mess in the Plex directory is. Or I can just write the same "shut it down, back it up, bring it back up" for every service, regardless of what database it currently has, what it may change to in the future, or what other databases some other service might decide it wants. It's an easy choice.