Maybe the Exim people don't feel like its worthwhile to rearchitect it, given that there are MTA's with more secure designs/implementations out there already.
SMTP daemon itself does not run as root (on default Debian it runs as "Debian-exim" user). Some processes do need to run as root for local delivery, as others have mentioned.
How exactly this exploit works around that I don't know. PoC isn't public. Bugs happen, even with secure designs.
https://www.openwall.com/lists/oss-security/2019/09/07/2
That implies it is the processing from the spool that is at fault; something is serialized and later read back.
* https://www.exim.org/exim-html-3.20/doc/html/spec_55.html
Like any MTA it needs to be root to connect to port 25. It can and does drop privilege after that. Like any MTA it needs to have a process running as root to do local deliveries as a particular user and to do .forwards . It appears that process is what is being attacked here. If you don't do local deliveries/.forwards, you don't have to have any processes running as root.
Exim itself dates from 1995[3].
I'm not really up to date on the use of capabilities, but it would seem that it can be setup before running the main processes anyway[4] using the setcap command (not sure how portable this is on other platforms, eg. BSD's) and it would appear to be a distribution/packaging issue in that context anyway.
There is also always the possibility of setting the port used for SMTP connections to a port higher than 1024 anyway, and using iptables/firewalld etc. to forward port 25 to that unprivileged port, as also discussed in [4].
Of course, neither of these options help in the specific case of needing to access user's home directories, either to read .forward files or deliver mail there directly.
[1] https://stackoverflow.com/questions/413807/is-there-a-way-fo...
[2] https://lwn.net/Articles/266521/
[3] https://en.wikipedia.org/wiki/Exim#Origin
[4] https://security.stackexchange.com/questions/71922/postfix-m...