Good questions! 
One of the most common use-cases for this was ShaderForge. Some artists used it, but everyone else only needed the resulting shaders. Since the package was rather large and added a lot of editor scripting that could/did slow down the editor, it was customary to have this package excluded from source control.
That still is the most viable option today for any asset that only some will use.
No.
At best you could modify the project templates the Unity Hub installs, however you’d have to do so for every new editor version!
It’s a lot easier to just create “My Template Project” and configure it as you please. Add the ubiquitous assets and packages, tweak the settings as you please, and so on.
Then, when you want to start a new project, instead of creating it from the Hub you’d merely have to copy that template project, rename the folder, then add it to the Hub and open it. Most of the times this will mean the project is upgraded to whatever editor version you are using, which will be fine. Personally I’d recommend to delete the Library folder before opening the project for the first time.
You can of course put your template project under source control and clone it locally. Perhaps add a script that automates the project duplication, renaming and possibly even adding it to the Hub (that’s just a json list with project paths). Though submitting changes to the template upstream are trickier. Either you do the same thing in both production and template project, or you cherry pick some files, export them, and import them back into the template project.
All things considered, creating your own template project and duplicating that to start a new project is still the most straightforward option around.
Alternative, more professional option is to maintain one or more custom npm packages with code and assets. You can then simply edit or replace manifest.json so that your packages are added and perhaps others removed. This means project settings will remain at their defaults.
Both options allow you to maintain custom modifications to assets you own.
Sort of but it’s a really low priority. You got the above workarounds, primarily the package workflow for developers who do in fact create many of them as their company’s foundational frameworks.
The other thing is you don’t know what might be causing issues down the road. Consider the case where a previous default setting is no longer the default, or even removed. That setting may change to something undesirable because the template project was created in an older editor version. This again may break some of the assets or code that your template uses. Sadly, many users would blame this on the Unity update being broken / buggy …
The same goes for bloated personal templates. There’s a huge tendency to do that among some. Even something innocuous like those Gadgets could end up slowing down the editor and you never notice, you just came to accept this degraded performance until you start a truly empty project.
Every now and then some developer stops by, complaining about 10 minute long script compile times. Turns out the project may have upwards of 20 GiB of assets in there, not counting the Library! If you add these one by one you ought to notice the pain they add to your workflow.