Worth nothing is the fact that the bootmapper client PCB uses the 32a controller, which lacks native USB support.
This results in slightly longer response times than you would get on a PCB using a controller like the 32u4, which QMK runs on.
For this reason alone I'd never pick the bootmapper version of the PCB, no matter if I would actually notice the delay or not.
Edit:
Also worth noting is that while the 32a does lack native USB support, I'm not sure how valid my claims above about response times actually are. This is something I've heard from other people, but when I tried researching it now I came up blank!
So if anyone else can share anything on this I'd very much appreciate it
From my understanding there's two things at play:
1) The V-USB that the 32a controller runs does introduce some theoretical lag relative to the native USB controller on the 32u4. It's probably on the order of sub-1ms. Reason being is that instead of there being an actual USB controller, the 32a is faking it by bitbanging two GPIO pins. Upside is this method allows for support of PS/2 as well - that's why you see BootMapper Client PCBs support PS/2 while TMK/QMK generally does not.
2) There appears to be much longer periods of lag when using a 32a controller on a 3rd party USB controller, especially if it's a Chinese clone of one. I suspect what is at play here is actually the controller rebooting, but in a short enough time period that Windows is just holding the packets instead of playing the USB disconnect/reconnect sound. My setup doesn't exhibit this issue, so I can't oscilloscope it to figure out what's going on.
Boards running QMK/TMK are at the forefront of development. The source is open, so you can tinker to your hearts content. The community has greatly expanded what is possible on a keyboard in those source trees (double shot, tap dance, split keyboards using a serial communication for cross-half communication, RGB underglow, I2C screens to indicate layer status etc). Downside is that it's harder to program than Bootmapper Client or JigOn. If your board is supported well by one of the web configurators, then it's just slightly more difficult. If it's not, or you need to add support yourself then you'll need some basic C++ knowledge. It's far from rocket science, but the knowledge floor for being able to work in the QMK source tree is far from 0.
Boards running Bootmapper Client are generally easier to program but they're missing some of the advanced features that QMK offers. Worth noting if you're into RGB, both Bootmapper Client and JigOn have better RGB underglow support than QMK does. QMK has a number of RGB modes, but it's lacking per LED RGB control which both JigOn and Bootmapper Client offers. Someone with the right skills could add it to QMK, but so far no one has stepped up.* JigOn and Bootmapper Client both use an outboard RGB LED controller on all of their designs, so the effects are a little more advanced plus they don't slow down the controller like RGB on QMK does. Someone on reddit measured controller response using the various RGB effects and the impact was all sub-1ms but it was measurable. Unfortunately, they deleted their account and I can't seem to find the post.
*Yes, the Zeal60 has per-RGB control but it's using an outboard RGB LED controller so that's really no help to the other 99% of QMK boards.