Can you compress an elliptic curve private key in half? According to this, an $n$-bit key offers about $n/2$ bits of security. That got me wondering, can you compress the key in half?
At first blush, no, because the key is essentially a random number, and so cannot be compressed.
But let's look at the private key relative to the public key. From an information theory standpoint, the private key has zero entropy relative to the public key.
So, given an $n$-bit private key $x$, can you produce a $n/2$ secret $s$, such that using $s$ and the public key $X$, you can efficiently calculate the private key?
This isn't the direction you were thinking of, however I believe that this is an answer to the question you meant to ask:

According to this, a $n$-bit key offers about $n/2$ bits of security. That got me wondering, can you compress the key in half?

One obvious approach would be to pick an $n/2$ bit secret $s$, and store that as your long term private key; then, when you're ready to start using it, you first compute $\text{SHAKE}(s, u)$ (where $u$ is some public identifier string [1]), and use the first $n$ bits of that as your private multiplier (which we'll call $t$, and so your public key is $tG$)
It would appear that the attacker has two possible approaches against this:

Brute force $s$; expected effort $O(2^{n/2})$

Use a discrete log algorithm to recover $t$ (which is just as good as $s$ to the attacker); expected effort $O(2^{n/2})$


It doesn't appear that there is a viable attack that combines these two; you can't tell if a potential multiplier is a possible value of $t$ without brute-forcing SHAKE; once you do that, you might as well stick with attack one.

[1]: We insert $u$ in the SHAKE call to try to avoid multi-key attacks (where an attacker is given a number of public keys, and tries to recover the private key for any one of them); it's analogous to the salt in password hashing.