From what I read here: It’s all about capacity for maintenance, I think. Once a plugin is an integrated part of Joplin core, it has to be maintaint by the core team, which is really, really small from what I know.
If a plugin is outdated…it’s maybe not nice, but no dealbreaker for the Joplin core as a whole.
And is it perhaps easier to add a plugin, than to integrate a function into the main code, if you as a developer just like to contribute this one desired functionality, that you need?
There is another aspect not mentioned ... speed. Each plugin or feature adds to the overhead of the program. And if you get a lot of them, you can see it start to affect your system. With plugins, you can install what you need, and turn it off or uninstall when you don't to save resources. If it was internal, you may not have this option.
IMHO there is only one plug-in so far that has the functionality that I believe would be better as part of the core package. That is the Simple Backup plug-in. I feel that users should have the facility to backup from the point of install rather than have to learn that plug-ins exist and then go and search to see if something is available to make backups.
I see plugins as a way to allow those 2 or 3 people that want a feature to have it without forcing everybody else to slow down their system. I've seen Joplin go from 94MB to today's 234MB and a lot of that may be due to new "features" that people have requested. Pretty soon it will move into the Evernote class where it will do everything, it will just take ten minutes to do anything. I love plugins because I can ignore those I don't need.
But then I don't have to use the plug-in whereas I would be stuck with the extra size of Joplin core. If every plugin was built into Joplin there wouldn't be many systems that could run it. Keep the plugins, keep the core size down and the speed up.
Sounds like given the code maintenance requirements, the efficiency argument might justify incorporating into the main app only those plugins with very high penetration. That might be a few at most; though one could argue that plugin penetration isn't very high because many new users are simply unaware they exist.
Determine the most popular plugins (how is a big question) and prominently bring them up on the opening screen. Promote the ability to do backups "with the plugin "xyzback" or the ability to locate left-threaded screws with the fantastic "Screw Locater" plugin or the "never lose that pen again" Pen-Finder plugin or whatever.
If people are complaining that Joplin can't do something, and there's a plugin that solves the issue, put the solution front and center when Joplin starts up for the first time. Bring the concept of plugins to the attention of newbies and solve two problems. One, the "it doesn't do this" complaint and two, help the first-time user get comfortable with the flexibility Joplin offers via an architecture that allows the expansion plugins afford. A quick link to the plugin page on the initial splash might help. At the very least it would allow Joplinites to say "It's your own fault, you didn't read the opening screen, did you?"
For sure there is a huge need for education regarding plugins. No shortage of threads here and on r/Joplin where people are asking for a feature that already exists via plugin. And for every person who asks on a forum about a 'missing' feature, there are likely many others who assume Joplin doesn't have that particular feature, and either live without it or move on to another note app.
I find this a slightly odd take seeing as the application that invented Electron, Atom, relies on packages for literally everything - the settings page is a package, the tree-view is a package, the command palette is a package. If anything this is exactly how Electron was meant to be used from the start.