> Every single application used to have a more powerful version of that by default

Kinda. Having tried to use various dark themes before in that era of theming, it was always a mess of broken applications, since you could easily get a dark-against-dark or a light-against-light contrast if one part of the UI picked up the theme but another part did not. If careful use of the theme colors is not enforced or tested, then themes will tend to be broken in enough cases to not make them worthwhile.

(I'm very pro themeing and customisation, but it's a lot of effort that everyone needs to be on board with to make it work, it's not enough to just make the tools available, you need to actively push them into use, and I think very few people have found that worthwhile: there's just about enough utility to dark modes for enough people for some developers to consider it worthwhile, but I think the longer tail becomes very unpalatable in terms of cost/benefit tradeoff)

This would be less of a problem now that dark/light mode has become a mainstream thing. Both normal users and developers often switch between light and dark, so bugs would be found quickly and solved with high priority.

The reason theming back in the day was often broken is because it was very niche. That one sysadmin using Linux with a satanic theme complaining about some dark-on-dark text won't even get a reply, but a customer's executive running macOS using its built-in automatic dark/light switcher complaining will be the top priority.

It's a shame the implementation went to a boolen dark/light instead of exposing a bunch of semantic color variables like old toolkits used to do, but we can "thank" designers for that one.