I think in this hypothetical scenario the uid 0 attacker can create its own node for /dev/rwd0 and use raw disk accesses to get around filesystem limits.
It's also hypothetical in that there's no known OpenSMTPd exploit that will allow you to get root, and barring a single CVE its record is pretty damn good.
Blind reliance on ACLs/MAC is dangerous itself. I've had the benefit of working on all of the above and ACLs aren't something people get right the first time. Most don't even get it right the 10th time.
We use SELinux in my current place and while it's fine, things break/fail in odd ways and we're always tweaking it.
In the 6-7 years I did Windows administration, I trained a couple hundred people on ACLs and specifically how the SubInACL tool should be used -- for all but about a dozen of them who truly grokked it, that training was an ongoing process over the course of those years...
OpenBSD's advantage is in its simplicity, which ultimately is the best security. If you have a system that you can clearly reason about and design for where it might fail, you are better prepared for "when" shit happens -- because it's not "if". If your entire system is properly architected, this isn't actually an issue.
For that particular example it should be pointed out that OpenBSD chroots the web server by default which ends up running as a non-privileged user. OpenSMTP does as much work as possible in multiple tasks running as a non-privileged user. So even ignoring the access control provided by the pledge system it is really unlikely that anything is going to escape to root or even be able to affect each other.
