No, but type safety does. You can't forget to lock an object before using it when that lock is part of the type. Or pass a raw user controlled path to a function that expects a validated one. If you want to do it on purpose you need to write unsafe code that's clearly visible to anyone reviewing your patch.

This said memory unsafe code just likely has more bugs because of all the footguns it has on top of all the other security work you need to do with it.

For most server setups OpenBSD's hardware support is adequate, and this is especially true for VMs. It's laptops, peripherals, and bleeding edge, high-performance or specialized devices where driver support is a PITA. But that's not something I've encountered running my own private servers. It would be nice to have something like ZFS, but mostly that's a peace of mind and convenience thing--would be nice to be able to stream backups somewhere rather than push around dumps and tarballs, though I have a script for that.

Can't have a bug in a feature you never implemented and can't have another arising from unexpected interaction of two features you didn't implement.

It's the one security practice that actuuuualy works

The orders of magnitude fewer security vulns for OpenBSD are not due to less testing. Everybody has always known OpenBSD is more secure, and it's not from using a different language. The reason is the code. Linux was not designed to be secure. OpenBSD was. It's that simple.