No, it's not hard at all. With standard derivation paths (and corresponding script/address type) including BIP44/49/84 etc, it works pretty well, across multiple wallets made by different vendors.
What's more, some "BIP39-killing" seed standards, like Electrum 2.0 seed and aezeed, share exactly the same word list with BIP39. Then what happens? Those ambiguous seed standards almostly effectively become yet another (much-blamed) "nonstandard derivation paths" themselves...
You keep using the term "standard" while there is no such thing in bitcoin. There is no centralized authority forming a standard committee defining what must or mustn't be used. Any developer decides what is the most appropriate approach and uses that instead.
In fact these differences are a good indication of existing flaws in mnemonic algorithms. (everyone is trying to address them in their own way).
the mnemonic doesn't give you any indication of the derivation path or the script types and since each wallet uses its own thing
After thinking about this problem, I think it's reasonable for a dev to feel bad about dealing with sh*ts (of unimaginable infinite possibilities) produced by other devs, or just themselves in the past.
This problem is not particularly created by devs, it is introduced at a later time when new scripts were introduced to bitcoin. For example there were no SegWit when BIP39 came out and users can create both legacy and SegWit wallets from the same mnemonic but while recovering they have to explicitly tell the wallet their address type or could end up with a wrong set of addresses.
You also have to see this from the eyes of people who aren't familiar with many details of bitcoin. There are those who don't know what P2WPKH means let alone want to select it when recovering their wallet from mnemonic.
However, unfortunately some (supposed) "BIP39-killer" seed standards like Electrum 2.0 and aezeed don't seem to be good precedences, because they are BIP39-ambiguous.
The alternative algorithms are each addressing different features that are lacking from BIP39 in their own way. For instance Electrum makes it flexible so that the algorithm can accept any wordlist of any number of words instead of the fixed 2048 ones BIP39 uses.
In my opinion, the "lack of version/type bits" is on the contrary a feature rather than a flaw - it means that you can adopt new coin types/address types/"accounts" (isolated subgroups of addresses) without redoing the boring backup job once again.
Good point but still having it is better than not having it. Besides you can still override the default behavior and derive any key at any path you like.
the word-lists and their inconsistency is mainly because over the years new lists were added and over the years the rules for new ones were improved requiring more unique lists with distinct words.
To check validity of a BIP39 mnemonic, a corresponding word list is needed - so what if word list is not known? BIP39 said: oh, maybe, maybe... you can just ignore it.

"maybe just ignore it" - that's the blamed inconsistency of BIP39.
I was talking about the words used in the word list and the inconsistency that exists for the rules required to choose a word. For example you shouldn't use words that are similar (aim, air) but some words lists like English do.
Also, how could Electrum 2.0 seed achieve its amazing feature of validating a seed without knowing the word list?
It does need to know the wordlist but it doesn't force you to use 2048 words in your list, you can have 10000 words for example or 3!
That explains why Electrum wallet GUI often seems to lose responding for several seconds during generating new seed - because it's still busy finding the required vanity seed for you.
What you are explaining is not about the word list but the algorithm used and it is a very fast one since it is simply computing a handful of HMACSHA512 hashes that is quite fast and should not slow down the UI at all.
If you are experiencing a slow speed it may be due to generation of all the child keys from that seed.