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.