Thanks for asking!

It's hard to pick a good default for this, and any different default will likely result in being "better" for some use-cases and "worse" for others.

The current default helps in scenarios where the container may not be handling signals, which is quite common if a pseudo-TTY is attached, e.g.;

docker run -dit --name foo busybox
time docker stop foo
foo

________________________________________________________
Executed in   10.17 secs      fish           external
   usr time   13.37 millis    0.20 millis   13.16 millis
   sys time   13.24 millis    1.06 millis   12.18 millis

Without the timeout, the above, would never complete. Some improvements in this area were made as well to provide slightly more control, for example;

• add --signal option to stop and restart docker/cli#3614
• implementing; Proposal: docker stop should allow you to specify which initial signal to use, instead of always using SIGTERM docker/cli#583

While the above works well for those scenarios, I concur that it may not ba a good one to choose for containers dealing with state, such as database-containers. I'm not sure if there's a good solution for that, at least not without it being a breaking change; while docker makes it easy to run a container from an image, and in doing so may help with pain-points such as dependency management, it won't take away from the fact that the user must get themselves familiar with the software they're running. If you're running (e.g.) PostgreSQL, you'd still need to know how it must be configured for your specific needs. And configuring it will therefore involve configuring both the software running in the container (postresql config), as well as configuration of the container (setting proper limits, attaching the right volumes for storage, but also setting timeouts like the one discussed here).
Some of that may be a documentation issue; image authors to provide examples, guidelines and recommendations for running the image in different scenarios (e.g. "production" and "development" settings may be able to use the same image, but likely will have different requirements w.r.t. such settings).

So.. are no improvements possible?

I think there are; besides documentation (mentioned above), I think some improvements could be possible; some of them would have to be taken carefully to prevent breaking users.

I think UX improvements could be made; for example, docker stop could show what's happening;

docker stop foo
Sending SIGTERM
Waiting for container to gracefully shutdown 10 9 8 7 ...
Container did not terminate within 10 seconds. Forcefully stopping the container using SIGKILL

We've been discussing more "interactive" approaches on the CLI, which could ask the user to either cancel or proceed with forcefully terminating;

docker stop foo
Sending SIGTERM
Container did not terminate within 10 seconds. Send SIGKILL? [n/Y] Y
Forcefully stopping the container using SIGKILL

Some (external) tooling to help and verify container configurations may also be useful for some scenarios (but probably out of scope for the core functionality of the docker engine itself).