CLINK is, at worst, par with Bolt12 wrt privacy. I think it's much better of course though, given the flexibility it affords.
First point of order is that Bolt12 itself doesn't actually help with privacy, things like blinded paths that it uses to justify those claims exist outside of it's context, and so the invoices CLINK serves can use that as well.
Where I think it's better is that Bolt12 is inherently tied to the receiving node for communications, where CLINK's use of nostr as an overlay network can use ephemeral or decoupled keys. It could even be used to fan out invoice serving across multiple nodes to keep an attacker guessing (our ref server doesn't do HA or randomization yet, but will eventually).
Also, since the transport is not using Lightning, that leaves fewer ways to leak metadata to your Lightning peers that could be used in a correlation attack.
Other things we can do in terms of roadmap, since we have nostr as an overlay network, is leverage that to coordinate things like lnproxy by @supertestnet which would effectively give nodes the ability to tap into a marketplace of obfuscating hops outside of the channel graph by sharding hop hints.
In short, privacy is ultimately a matter of implementation rather than protocol, but the flexibility of CLINK in using nostr as an overlay network allows those implementations to do everything Bolt12 does and much much more.
lnproxyby @supertestnet which would effectively give nodes the ability to tap into a marketplace of obfuscating hops outside of the channel graph by sharding hop hints.