The simple answer is that there are two reasons:
- The lack of a standard implementation. RSA has an acknowledged standard while McEliece doesn't.
- The size of the key. It's huge! In the multi-megabit range. In terms of today's communication networks, that is bad, but - in my opinion - not too bad. It means it takes time to exchange, but once you have built up your local DB of keys for actors that you communicate with, well, so what. But storing the keys is another matter. You can't just pop them in to a varchar field: you need to really think about your local key storage issues.
That said, I think that there is a definite use case for McEliece coming. Especially if you have secrets that have to be secure for a long period of time.
Current PKE used for thanks like SSL and bank transactions is fine: the time to live for the transaction is relatively small. But think of the security around a property transaction using smart contracts: lots of property is held for > 20 years. If the title deeds are proven via a secure document then you need the security on that document to live at least that long - probably many times that length.
Just for fun, I downloaded a version of McEliece called CodeCrypt, compiled that and generated a key. It took 9 minutes of CPU time!
Now, if I have done this all correctly, the public key is only 4K, and the private secret 20K, which is either way too short, or (more probably) I have made a mistake somewhere.