I am the parent, and any competent fsck should find these issues. Fsck traditionally explicitly verifies claimed free space against actual free space, and in a filesystem with ACLs it should also verify that filesystem level metadata like ACLs is sane, just as fsck verifies (for example) sane inode flags and inode field values. ZFS scrubs explicitly do not verify spacemap consistency or a lot of other sorts of consistency.
ZFS scrubs don't even verify that a filesystem's directory tree is acyclic and can reach every claimed in-use filesystem object, but I'm not aware of ZFS bugs in that area. This is because ZFS's 'metadata' for scrubs is much different than how it works in a traditional filesystem. To phrase it in conventional filesystem terms, ZFS has a big list of all in-use inodes, and it verifies the filesystem checksums by going through this list. The 'filesystem metadata' that a scrub verifies is the structure of this list of in-use inodes, plus some other things around the corners.
The article is correct but it downplays an important limitation of ZFS scrubs when it talks about how they're different from fsck and chkdsk. As the article says (in different words), ZFS scrubs do not check filesystem objects for correctness and consistency; it only checks that they have the expected checksum and so have not become corrupted due to disk errors or other problems. Unfortunately it's possible for ZFS bugs and issues to give you filesystem objects that have problems, and as it stands today ZFS doesn't have anything that either checks or corrects these. Sometimes you find them through incorrect results; sometimes you discover they exist through ZFS assertion failures triggering kernel panics.
(We run ZFS in production and have not been hit by these issues, at least not that we know about. But I know of some historical ZFS bugs in this area and mysterious issues that AFAIK have never been fully diagnosed.)
I can't remember the 10G firewall figures we got in testing off the top of my head, but we didn't max out the 10G network; I think we were getting somewhere in the 8G range. This is significantly better than our OpenBSD performance but not quite up to the level of full network speed or the full speed that two Linux machines can get talking directly to each other over our 10G network. I also suspect that performance depends on which specific NICs you have due to driver issues. The live performance of our deployed FreeBSD firewalls is harder to assess because people here don't push the network that hard very often (although every so often someone downloads a big thing from the right Internet source to get really good rates).
The short version is that we wound up not feeling particularly enthused about OpenBSD itself. We have a much better developed framework for handling Ubuntu machines, making it simply easier to have some more Ubuntu machines instead of OpenBSD machines, and we also felt Bind on Ubuntu was likely to be better supported than a ports Bind on OpenBSD. If everything else is equal we're going to make a machine Ubuntu instead of OpenBSD.
The computers that moved from OpenBSD to Ubuntu were our local resolving DNS servers. These don't use PF and we also wanted to switch from our previous OpenBSD setup to Bind, where we were already running Bind on Ubuntu for our DNS master servers. The gory details were written up here: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/UsingBindN...
We may at some point switch our remaining OpenBSD DHCP server to Ubuntu (instead of to FreeBSD); like our DNS resolvers, it doesn't use PF, and we already operate a couple of Ubuntu DHCP servers. In general Ubuntu is our default choice for a Unix OS because we already run a lot of Ubuntu servers. But we have lots of PF firewall rules and no interest in trying to convert them to Linux firewall rules, so anything significant involving them is a natural environment for FreeBSD.
mypy sadly doesn't accept 'NewType('MyType', Any)'; it complains 'error: Argument 2 to NewType(...) must be subclassable (got "Any") [valid-newtype]'. Possibly this is allowed by other Python type checkers. It is accepted at runtime, and I wish mypy allowed Any as a specific exemption to its checks.
ZFS scrubs don't even verify that a filesystem's directory tree is acyclic and can reach every claimed in-use filesystem object, but I'm not aware of ZFS bugs in that area. This is because ZFS's 'metadata' for scrubs is much different than how it works in a traditional filesystem. To phrase it in conventional filesystem terms, ZFS has a big list of all in-use inodes, and it verifies the filesystem checksums by going through this list. The 'filesystem metadata' that a scrub verifies is the structure of this list of in-use inodes, plus some other things around the corners.