Integration is hard. So yes, people prefer to make new packages, this
way whoever likes it can install it and those who don't like it won't
be affected.
I don't think it's necessarily a problem. It just means integration has
to be done separately. Nowadays it's done at various places by
various people. It's done here on emacs-devel, of course, but it's also
done in all the "Emacs distributions" like Doom, Spacemacs, ...
Having several distributions makes it easier, because the affected users
can go elsewhere when they're not happy, so while emacs-devel is quite
conservative, other distributions can be more daring.
+1. I don't think this is a big issue. There are pros/cons on both sides and neither has significant advantage over the other. Personally, I like having ELPA and Emacs be a minimal core which I can extend and add via packages to get the environment I want. This tends to keep the core stuff smaller and less complex, leading to less bugs and easier maintenance. The downside is that when things in core ELPA/Emacs are updated, add on packages may be broken until the author/maintainer gets around to updating them.
As someone who has/does maintain code with a free and/or open source license, I know from experience that contributions, enhancements and extensions can be a real problem. I have one library which has become much harder to maintain because I accepted enhancements from others. While those enhancements were well written, now that they are part of my package, I'm left to maintain them even though they were not enhancements I needed or wanted. They have made my package harder to maintain and consequently, takes time I really don't have. However, because it is now part of my package, I either have to maintain it or remove it and the associated functionality, potentially frusrating some users. In hindsight, I wish these enhancements had been added as separate packages that extended my lib. I am now much less willing to accept pull requests that add new features or functionality.
I think org-mode is probably a good example. There are many extensions and enhancements to org-mode and many of them are separate packages. There are still some things in org-mode core which probably should be separate packages. The majority of these separate extensions/enhancements are not things I'm interested in, so I don't want them installed. I'm pleased all these extensions have not been added into the core as if they did, development of core functionality would slow down and would likely become more complex and buggy. The downside is that when a new org-mode release occurs some of the add on packages I use may be broken for a time. However, perhaps that doesn't matter or perhaps I may choose to pin the version of org-mode to one where the add-on does work. If an add-on becomes really popular and used by a majority of org-mode users, then perhaps it becomes a good candidate for inclusion into org-mode or the functionality it represents can be added to org-mode (negating the need for the add-on, but possibly with a different implementation).