No one else does.

When I shutdown I would like a shutdown sig to be sent to my database and then continue once it gets a successful response. No one wants that to just be killed because that would cause data loss.

When I shutdown I want my filesystem synced so things mid-write don't experience data loss.

The problem is badly written scripts that keeps sending a "one more min" response. But you could override that if you actually cared instead of just whining.

If your database loses data when killed it is not worth the bits it is made of.

Is a transaction is still in flight and is not committed then you will lose it.

Just because you decided to kill the database while it was still in use, that's your fault.

To my understanding systemd does proper job here, as it supposed to be, highlighting the issues with other subsystems - be it badly written scripts or misorder of shutdown sequence, those parts were ignored by "traditional" init systems before.

Exactly my point.

If it is taking 5 mins for my db to respond with "success" then either fix the db or switch it.

That's not systemd's fault that the database is rubbish.

Also, systemd comes with a timeout, after which it kills the app anyways, so I think you can surely configure that 90s timeout to be something like 5s or so, which then is much faster.

But as you wrote, If someone really cares, they would fix it.

PS: But what usually gets me about these 90s waits whenever I get them is that the message does not say which thing (unit, etc) is the issue. THAT is something worth criticising.