@agl of the chrome team directs developers who want to communicate with U2F (FIDO/WebAuthN device) to use WebHID.

I don't think that's an accurate summary of the quoted text but, to be clear:

Devices that are stuffing unrelated protocols inside U2F in order to skip the device-selection UI of WebUSB / WebHID / etc should stop doing so. (Hopefully that's not too surprising.)

What you're talking about are devices that are security keys, but want a side-channel for configuration. You say that SoloKeys “supports seeding their security keys via a CTAP protocol”. I'm not sure what that means but if it means that there are magic structures in opaque makeCredential or getAssertion commands, then that's tunneling and not allowed. If it means that there are CTAP2 vendor commands then that's fine, but you won't be able to exercise them via the browser as the CTAP channel is reserved for security reasons. On Windows you will need Administrator access since otherwise security keys are blocked at the system level.

If the configuration is on a different HID usage page then the problem is that I'm not sure whether it's possible to reliably separate reports on a per-usage-page basis. Most robustly, if the device presents as two different devices on the USB bus then the second can be used for configuration via WebUSB. Perhaps just a separate USB interface is sufficient but that might fall afoul of the Windows restrictions.

We are not trying to circumvent the device-selection UI, but if access to WebHID is blocked it sounds like developers are being pushed toward tunneling.

Correct, that SoloKeys supports a CTAP vendor command. Why not allow vendors to opt onto an allow list, at least where platforms don't require chrome to have root? Why address the question of tunneling over U2F by telling developers to use WebHID when communicating with U2F then forbid WebHID for U2F?

Why address the question of tunneling over U2F by telling developers to use WebHID when communicating with U2F then forbid WebHID for U2F?

People are building devices that are unrelated anything security keys, but choosing to export a FIDO usage page and using the U2F API in the browser, because it avoids any user interaction. They should not be advertising the device as a security key but rather using WebHID / WebUSB as intended.

You are in a niche where you're trying to interact with additional functionality on a device that really is a security key. In that case you'll need to expose only that functionality via a separate USB device, or at least interface, to provide separation.