I don't think it's only theoretical. It's an implementation error that can leak your private key given the right circumstances (that an adversary could probably engineer). What the NIP-44 security audit has to say about this might help:
NOS-01-001 WP1: Potential twist attacks in secp256k1 implementations (Info) Cure53 has evaluated NIP44 in terms of its resilience to twist attacks. Although the current implementation was not found to be vulnerable, further steps can be suggested to make sure this state persists.
Twist attacks are an issue with naive implementations of the secp256k1 curve. They envelope problems with certain sanity checks, which can cause leakage of sender’s private key in the NIP44 protocol.
More precisely, this applies to implementations of secp256k1, which accept uncompressed representations of public keys. This means public keys are represented with both x and y coordinates instead of just x and a sign bit. As such, failure to verify whether these public keys are actually on the curve or not should be considered.
Encryption with a key, which is derived from an ECDH-computation on long-term keys of different parties, leaks the private key of the sender. The risk appears when a sender is tricked into encrypting a message with an invalid public key, i.e., one that is not on the real curve, but on a similar curve which admits small subgroups. In this context, the sender can leak their private key. For a more precise description of the twist attack, refer to Lundkvist’s blog post.
It is noteworthy to mention that the related ECIES encryption scheme, due to not using the sender’s private key, does not suffer from this particular issue. Nevertheless, it is still important to avoid such naive implementations, since they may lead to suboptimal security. Similarly, key-exchange variants, where senders provide an ephemeral key pair in addition to their long-term secret key, cannot be securely implemented with uncompressed and unverified public keys.
The current NIP44 implementation includes tests that make sure that deriving keys from invalid public keys fails. Cure53 suggests including more tests specifically designed to catch twist attacks (see NOS-01-003) and also describing valid keys in the specification (see NOS-01-002). It is known that uncompressed and unverified public keys can lead to other security issues.