@Tomm#0017 so... I think to understand my thoughts on plugins, we need to go back to when I was working on servers like rs2hd and the very initial release of Apollo. Back then development worked a bit differently in the RSPS scene - very little use of version control, people tended to just work on a server, post a code dump when it was finished and then abandon it. Although there were Git hosting services like SF, Assembla, etc. (and perhaps even GitHub itself had started by then?), GitHub wasn't that popular and none of the existing services had as much as a focus on collaboration and things like pull requests, forking or code reviews. Furthermore, the average standard of an RSPS programmer was significantly worse than it is now, and so was the code quality of all the servers. And I discussed this at length with Blake at the time, and we basically decided that a plugin architecture was the best way to go - you'd have a core team of decent, trusted devs who could commit to the core repository, and everyone else who wasn't necessarily trusted to have direct commit access could extend the server with plugins instead - so it'd solve the collaboration problem. Furthermore, the plugins could be in a simpler scripting language than Java (Python in rs2hd, Ruby in Apollo), which would make it easier for inexperienced programmers. The core server itself could be distributed as a binary (back then many people struggled to even configure their PATH variable), and there could be an online repository of plugins that people could download and enable/disable. So really a lot of the problems it solves, I think, were actually to an extent not technical problems, but the social problems of the scene and the state of collaborative tools like GitHub.
In the subsequent years since I worked on rs2hd/Apollo, I've slowly come to realise that a plugin system does add additional technical problems. For example, how do you decide the exact API boundary? If too much is in the core, the plugin system isn't flexible enough (and even Jagex have this problem, with their content developers often claiming that they need to wait for "engine time" to be able to solve a particular problem). If too little is in the core, then plugin developers have to implement a lot more code themselves, and duplicating code between plugins might reduce their ability to interoperate with each other (e.g. imagine if two different plugins had to reimplement various functions for manipulating the player's inventory).
Another problem (at least for rs2hd/Apollo) is mixing two languages, which caused the IDE experience (e.g. autocompletion) to be less good. However, this point is less important, as it is fixable - e.g. use the same language for both the core and plugins (e.g. like Bukkit did with Minecraft) or one that it is compatible (e.g. Apollo's new Kotlin plugin system).
Refactoring also becomes more difficult with plugins (especially post release) as you have to maintain API compatibility and any sort of refactoring you want to do to that API boundary will take a long time to do, as you have to get everyone who is working on plugins outside of your main repository to upgrade before you can deprecate the old API, and you'll have to go through the hassle of having two copies of the same API running simultaneously for a while. In fact, this argument is quite similar to the arguments that come up when people discuss using several different repositories vs a monorepo, and I think there's definitely a parallel to be drawn here. (And no surprises, I'm also a big fan of monorepos).
I think some people in the scene also misunderstand what plugins can be used for, or at least rs2hd's/Apollo's implementation of them. A common misconception back in the day was that plugins would allow content to be updated while the server was still running, but at some point in rs2hd's development and before I even started on Apollo I basically realised all the problems this causes (you have to deal with state - what do you do about variables that are added, removed or changed by the plugin that is reloaded, for example?) and I basically decided to ignore the problem by not supporting reloading at all.
I think something that has come up with Apollo is that certain plugins ultimately need to depend on each other, which basically negates the benefits of doing out-of-tree development and the idea of having distinct plugins in a repository that you can pick and choose - they ultimately end up becoming intertwined with each other anyway. e.g. even something simple like the attacking dummies plugin needs to depend on whatever plugin implements certain parts of combat, as it needs to know the correct attack animation to use for the weapon that you're holding.
Now, if we go back to the original social reasons for creating the plugin systems, I think that 10 years later the situation has changed. GitHub is significantly more popular than it was, and people are more familiar with it. You don't need to collaborate by trusting people with commit access - they can fork the repository, make their changes independently, submit a pull request, which you can then review to ensure they didn't go too crazy, and finally merge in. The simpler language argument goes away in two ways: (1) on the whole, RSPS programmers are better than they used to be and (2) to solve the IDE integration problems, modern servers like StrongHold are using the same language (or at least a compatible language, in the case of Apollo) for both the core and plugins, so the simpler scripting language for noobs argument becomes invalid.
In reality, if a plugin-based server ever took off, I think we'd eventually see people settle around a common group of plugins that are always installed for base functionality like all the skills, combat, and so on. In general, I think the "pick and choose" argument isn't really necessary, and at that point it's much easier to just stick all that base functionality in a single monorepo. At that point, you can start blurring API compatibility and the exact API boundary, making development a bit more flexible as you can refactor things freely.
So I think my chosen solution these days would to not have a server be plugin-based, and just develop the core and content in the same repository. Now, this isn't to say that they need to be mixed up like spaghetti - you can still architect things properly to split the server up nicely, use Gradle/Maven modules/subprojects, and so on - mainly because all the social issues can be solved in a different way these days, and plugins do actually impose additional technical problems. And I think a single repo also solves the social issues, but without introducing new technical problems.
Now, there is one point I haven't addressed, and it's one I don't actually particularly care about because I'm a bit of a purist when it comes to RSPS development. But I think one good use case of plugins would be for people who are interested in custom content, rather than emulating what Jagex has done. As at that point the people developing the core server might not want any custom content, and would want to leave that to their users. And at that point, plugins still make sense imo.