Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?
Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.
Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.
There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?
How do branches make it more difficult? You're intentionally conflating two different use cases. You want to do all your work in master and periodically push to a central server? Fine. I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed. I want to keep them in a branch so the work doesn't slip into a release. When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.
Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.
In Git you don't have to have one or the other scenario. You can have both at the same time. Branching off of a release branch and merging later back into that branch is just as simple as branching off of master. Merging and Pull requests allows for flow management on teams that may have owners of various pieces who need to review anything being committed against their branch/module/whatever.
No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.
I never said that Git is the Right Answer For Everybody - thanks for putting words in my mouth. If your preferred workflow doesn't map to the Git model, then don't use Git. Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.