Previously the tagToEnum# was optimised away in the code generator in the common cases. Perhaps the Simplifier will do that for the wrappers now, I don't know. This special case is still in the code generator and it will be there until we move handling of tagToEnum# to Core. So using wrappers changes nothing - generated code is exactly the same as it used to be. Nothing gained, nothing lost.
But if people are using primops, they are probably deliberately writing low-level code and they don't want to be relying on optimisations that might not happen. In which case they are free to modify their code to use the new primops. The only concern being that perhaps they might not be aware that what used to be a primop is now a normal function. But I'd assume that if someone decides to use primops then they are at least moderately following changes in the internals of GHC and will spot out that change in the release notes. That's my optimistic assumption.
I don't mind breaking these very low-level APIs. We are breaking that API at the moment, except that you propose to break it by chnaging type signatures, whereas I chose to break it by changing names. So currently the change in primops will not go unnoticed.
We could always provide a GHC.Prim.Compat Well, that's what GHC.PrimWrappers is currently - it provides backwards compatibility (except for a few functions that Simon PJ pointed out, but I can easily change that).
Janek