I don't know about Yubikeys, but if they can sign their emitted plaintext, they could be used to similar effect.
The module only supported two interfaces:
1. Network -> Buffer, where it takes a packet with a particular structure and encrypted data and emits a signed plaintext.
2. Buffer -> Network, where it takes a request, result, and proof object and sends them out after signing and encrypting.
We were using it to front solvers that did a lot of work to solve constraints and emitted a proof object, so clients would send us requests (not our problem how they generate them) and then we had to show we did the right thing. The CPU didn't know either key, so it could either:
1. Compute the right thing, have results signed.
2. Compute something that doesn't match the signed request; have its faulty proof signed and returned. (Detected by the consumer when they verify.)
3. Fail to compute.
So this was guarding the case where a CPU was compromised and could possibly emit faulty (or malicious) results.
The point is that HSMs can allow for securing a computation chain if you can securely sign the root, even against compromised CPUs.
Most interactions with remote servers involve higher-level crypto primitives, but if a secure client has these keys it should be possible to interact securely with a remote YubiHSM (assuming secure initial setup, keys must remain secure, etc.).