As far as I read up about this some time ago, it boils down to the following reasons:
- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures
- CVS is preferable for their current contribution workflow (centralized)
- CVS is treated as a tool that, currently, just works (tm)
It seems ever-so-slightly ironic that support for exotic architectures is considered a plus in this case, while support for exotic architectures is being ripped out of the OpenSSL/LibreSSL codebase. (Though probably not deeply ironic, since CVS is comparatively simple.)
It might seem ironic to people who do not understand the difference. OpenSSL includes wrappers and (probably untested since N years ago and therefore broken) code branches to work around bugs in old broken exotic systems that do not get fixed. This sort of code is a maintenance burden if you try to keep it working and just useless if you don't. It is also likely to introduce bugs. Getting rid of it simplifies the code and gets rid of bugs along with it.
OpenBSD's system level support for exotic platforms has more to do with drivers, compiler & tool chain support, boot code, etcetra. These do not create a jungle of ifdefs and workarounds in userspace applications. And if these platforms are broken, they are fixed instead of worked around with more jungle and weed. So support for these things does not add bugs for others.
On the contrary -- getting your software to run on a SPARC64 is more likely to expose flaws in your code.
- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures - CVS is preferable for their current contribution workflow (centralized) - CVS is treated as a tool that, currently, just works (tm)