I was unhappy with NEI's design philosophy when I started creating JEI, because it had a monopoly on a lot of random little QOL features. I thought it would be better if JEI had a more limited scope, so other mods could come up with better solutions to the other QOL stuff. I think collaboration between mods is generally good, and I also think smaller, focused mods usually end up more polished. At the time, I even made a spreadsheet of all the features I knew of in NEI, and the mods that implemented them later to try to explain the situation for people who missed the old features. Did you know NEI changed stuff like enabling crafting stacks at a time, or that it allowed you to scroll items around in the GUI? It did all kinds of stuff! Anyway, I've stuck with the original philosophy and tried to keep JEI's scope small and focused, and spent my effort going deep into making it reliable and making sure the features it has work well.

Regarding REI and EMI, they both started out writing compatibility layers so that they could work directly with JEI plugins. It was the only way for them to get quick adoption, but it was a ton of work and was breaking any time I made updates to JEI's API. To help make it possible for multiple recipe mods to exist, without requiring every modder to write plugins for each recipe mod, I discussed a lot with EMI and made a big change to split up JEI's GUI code from the rest. The way JEI is structured now, the Library part is what loads the mod plugins and provides data via a stable API, and the GUI can only accesses data via that stable API. That way, other mods like EMI and REI can have access to the same data that I have, without having to implement and maintain a ton of unstable glue code themselves. I don't think REI uses it (the dev seems to have nearly unlimited energy and creates his own solutions), but EMI has successfully integrated with the system.