Fifteen years of KDE

I guess if someone wants to have their mail client download headers for all mails every time they click on an IMAP folder they will find an alternative mail client that never ever accesses local storage.

But such a person would have not used KMail at any prior version anyway, because it also did cache headers.

Fair enough, but I hope you understand that it's not a viable option for everbody. A caching service that can be configured through GUI or does not require any configuration at all is targetted at a different type of user.

Mail clients such as KMail or Thunderbird (and most likely also Evolution) acknowledge that this other type of users exists and thus are capabable of providing caching themselves.

I am confident that there are mail clients which target users such as yourself who can take care of such features externally.

"I've been using KMail for years and years without the added complication of a »DB engine«, and I can frankly see no benefit whatever in the added complication."

Choosing to use software components developed by experts in their respective area is considered a common and recommendable practise, i.e. using established libraries and services instead of implementing everything again (often referred to as as "reinventing the wheel").

A couple of years back a lot of programs used to have their own handcrafted code to deal with relational data, usually using some program specific binary format for data and index files.

Nowadays most of these programs have switched to using existing relational data handling code, usually written by people with a lot more experience in dealing with such data than the end user application developer using the library.

KMail used to be one of the applications that still had its own way of dealing with such data, using its own proprietary index format, etc.
It has just followed the trend to use established and well maintained external code for that. If you need any examples of other software doing that check your package manager's reverse dependencies for libsqlite.

It might look like a weird choice from a user's perspective but a lot of software developers seem to agree that this is a good thing.

"Show me one compelling reason why I would even want to run a complete MySQL or PostgreSQL server just to power my mail reader and I might reconsider."

There is quite a range of possible implementations for relational data handling, the two you are referring to here use a service based approach where engine runs in its own process and clients commmunicate with it.
Other implementation run the engine within the client process, e.g. SQLite.

Depending on factors such as size of data set, access concurrency, support for transactions, etc. some implementations will have different advantages and disadvantages.

Therefore different weighting of these factors will result in different ranking of solutions. If your needs are better matched by an in-process implementation then you should be using one. I don't see any value in trying to persuade you otherwise, after all you know your requirements a lot better than anyone else.

Whether some software you are using is capable of using different implementations is of course dependent on whether its developers anticipated a need to have this kind of customizablity.
In the case of KMail, or more specific Akonadi, this is possible.

Akonadi is neither autostarted nor restored by a session manager (unless one manually adds autostart support files, which is highly unlikely in your case), but started on-demand by first client.

I think there is a list of less known clients on userbase.kde.org which are known to cause Akonadi startup for users who are strictly against PIM data integration features.