Would not be a bad idea. With Github actions, doing CI builds for plugins and wordpress should be fairly easy to do with either dockerized mariadb or sqllite. Set up a little matrix build. And for good measure, maybe support nginx and posgresql as well out of the box. Nothing to incentivize plugin developers as having a few red warnings next to their name in the plugin registry.
I setup builds for most of my oss projects. It's not that hard. Of course at the scale the wordpress community operates, this would require some non trivial amount of resources.
Your very comment would be enough to turn off 60,000+ plugin developers and 50% of the web who uses WordPress. Nobody likes anything being forced on them there. Less, non-prominent OSS projects trying to force their way in through such arrogance.
WordPress will surely rot if a rather-weakly adopted database engine is not forced upon its entire ecosystem. You can be sure that the flower shop owner somewhere in Idaho, who uses WooCommerce for his flower business and the random anime blogger somewhere in Tokyo, who uses WordPress for blogging, will be hampered by that.
Are you saying that SQLite is weakly adopted in general or weakly adopted in WordPress? The former is rather far from the truth[1], while the latter is rather obvious given that WordPress doesn't support it yet...
Leaving aside that the claims there need to be taken with a grain of salt since there are equal comparisons for most other engines:
There is absolutely no need for SQLlite compatibility in WordPress ecosystem. That is 50% of the web. There is no business, user, or programming case that would require it.
The proposition that a software should support something because a browser or a handheld supports it is illogical from the start. Why.
> WordPress’s minimum requirements would be a simple PHP server, without the need for a separate database server
That doesn't help anything. The complications come from the plugins and themes that make the WP ecosystem. Not the WP core itself.
> SQLite support enables lower hosting costs, decreases energy consumption, and lowers performance costs on lower-end servers.
Thats too extreme a stretch. The flower shop owner in Oregon has bigger concerns than contributing to those with 0.0001%.
> This can be translated to lower operational overhead and faster loading times for small-database sites, and that equals money.
It doesn't, really. The reality of the software and infra costs in the industry is that they are already pretty low. And the meager improvement that will come with adoption of anything - leave aside SQLlite - just do not merit the effort that will go into doing it.
Majority of the web hosts already use reverse proxy caches that directly serve HTML instead of ever contacting the database. This applies to majority of the WP traffic including ecommerce traffic. If you are visiting any prominent WP web host as an anonymous user, you are very likely seeing a static HTML being served to you without db ever being contacted.
And in the case the db is contacted if the host does not have a reverse proxy cache or anything, it is only being contacted to get a minimum amount of information with the simplest of queries, and then again, a static page is being served from a caching plugin's cache.
Going further - if you are actually a logged in user, using a WP website without being served a cache and actual WP queries are happening, the chances are high that few of the queries that are happening can ever benefit from any db engine that is 'more optimized'. The majority will just use standard stuff, with MySQL servers that are already optimized for it.
So, all the glorious improvements that you imagine are not applicable in the real world. That's why nobody will lift a finger for it.
I setup builds for most of my oss projects. It's not that hard. Of course at the scale the wordpress community operates, this would require some non trivial amount of resources.