For the time being P-256 is really only your only choice if hardware token and enclave support matter. FIDO2 tokens support Ed25519, but only using a custom signature format, and anyhow many of the most popular FIDO2 tokens also support P-256 via PIV smartcard interface. TPMs, Apple T2, etc, only support P-256, and they're becoming ubiquitous on laptops.
You may not think hardware support matters, but which is more likely: somebody breaking your private key remotely using a side-channel attack, or a trojan exfiltrating a key? The latter should be more of concern in many if not most scenarios, especially where an app or protocol is only signing upon interactive user requests. Historically developers tended to give this hardware token support short shrift because the ecosystem was too difficult to work with, so they could just write it off as not feasible. But API support on macOS/iOS and Windows has become much simpler over the years, while hardware more common, and so it's increasingly difficult to take that stance.
> You may not think hardware support matters, but which is more likely: somebody breaking your private key remotely using a side-channel attack, or a trojan exfiltrating a key?
As a cryptography engineer, this is a good reason to urge Apple, et al. to support Ed25519, not to prioritize P-256.
(Of course, by all means, prioritize P-256 until we can succeed at getting these companies to correct their course on Ed25519 support. But long term? We want Ed25519 to become ubiquitous.)
Maybe it'll happen, but one thing to keep in mind is that canonical EdDSA signatures (i.e. PureEdDSA) require feeding the entire input stream, not simply a hash of the input. That can be problematic or even impossible for hardware tokens, as well as other scenarios--e.g. BearSSL's API has to be substantially refactored to support X.509 EdDSA signatures, a refactor which may never happen. So when devising and/or implementing a protocol one must consciously choose the supplemental HashEdDSA variant, if one even has the choice. But as long as people indulge make-perfect-the-enemy-of-good urges, that's yet one more hurdle many won't overcome. (And hesitancy is actually somewhat understandable in this case as DJB and others explicitly discounted the value or need for secure hardware scenarios; they were explicitly optimizing for the most common scenario in typical FOSS environments where the private key is local in software.)
Perhaps Ed448 might gather more momentum as it wouldn't be a direct replacement for P-256. And usage isn't quite as common so selection of the prehashed variant may be more practical. But it's entirely possible we won't see a shift in hardware support as widespread as RSA -> P-256 until quantum-resistant schemes are settled.
You may not think hardware support matters, but which is more likely: somebody breaking your private key remotely using a side-channel attack, or a trojan exfiltrating a key? The latter should be more of concern in many if not most scenarios, especially where an app or protocol is only signing upon interactive user requests. Historically developers tended to give this hardware token support short shrift because the ecosystem was too difficult to work with, so they could just write it off as not feasible. But API support on macOS/iOS and Windows has become much simpler over the years, while hardware more common, and so it's increasingly difficult to take that stance.