And SQLite respond to bugs with a lot more professional attitude. They apologise, they fix. They try and ensure it won't happen in future. They do not make excuses.
I really don't think that often hated "Not my problem" kind of answers Pottering gives are that unprofessional, because in 99% of cases, he points to exact party who's problem it is and mostly they are distribution maintainers, which makes sense.
Except, defaults matter. If you ship something that violates decades of well-known behavior, it is at least very unfair (and probably a lot of other unpleasant adjectives) to expect downstream to enable the —suck-less flag to restore the expected behavior.
The friendly and not bull-headed thing to have done was to ship the new behavior, but enable the compatibility flag by default, rather than expect other people to clean up after systemd's messes.
This mentality is the main reason bag on systemd all the time. If systemd does something to annoy you, it is automatically your fault for doing something Wrong or not enabling some obscure config file option. It's never systemd's fault when systemd unilaterally violates the principle of least surprise.
Debian maintains hella lot of patches for almost every package because of reasons I can hardly justify. Overriding a few systemd config files is nothing. But let's say systemd sets some sane defaults and everyone happy. Or are they? Like, for instance default NTP is "centos.pool.ntp.org". Oh, crap, Debian still can't use it.
They don't dismiss concerns - they validate them.