It’s key to remember that putting something in Sponge directly that is a “Feature” more than an API actually is bad for you in the long run!
As I said on another thread - If it’s in Sponge, it can’t be improved as freely as it has to make sure it doesn’t break anything implementing it.
Also, theres the case of “who’s using it”. When you go with a plugin controlled route, you get the benefit that the developer of the plugin can put their focus into said plugin, and provide the features they need.
There is self gain that drives the development of the plugin and the features.
Now, if you go putting it into Sponge itself, your personal desires are now restricted to how it affects EVERYONE else too. This can and will limit you at some point.
That’s why API’s are API’s, they define the basics, then let other things implement.
So stuff like full on permission managers, economy and anti cheat? No, you DON’T want that in Sponge.
This is why I have many powerful API’s in my own custom fork of Spigot that I haven’t contributed upstream. You lose a lot of flexibility when something becomes officially part of the project, and I didn’t want to sacrifice that.
If you want to have a nice permission manager or anti cheat that is free to evolve and become even better, then you don’t want it inside of Sponge core itself.