My point on enabling/disabling SSL by default is that Solr is often behind firewall and near to back-end which use it, they are both in some kind of private network, so TLS will be cpu, network and management overhead for such cases. I believe that it's primary use case and exposed Solr installations are rare.
Also, requiring admin UI auth seems to be a good idea only at first glance.
Under the cover it will require non-trivial role model to separate user actions and admin actions on all available handlers (like discussed in
SOLR-7838) which heavy depends on configured handlers and use case: sometimes update is normal action for user and delete by id is not, sometimes delete by id should be allowed, but delete by query shouldn't etc.
Another potential issue with self-made security framework is creating high quality security modules. If some of them may be created and distributed with Solr, so pass some QA by Solr committers, third party modules can have lesser quality and affect overall Solr experience. Buggy or just slow third party security filter will lead to bad user experience. Credentials and authN/authZ rules caching and synchronization are other hard-to-implement-correctly part, especially in distributed environment.
Since role to user mapping is non-trivial and authN/authZ is hard to configure, security setup as standard Solr installation step would be frightening for many users. I think, it should be optional for users, who want or have to use such security model.