From my perspective, these are policy decisions that need to be made by some "management-ish" level. Git provides the mechanism to do all of them. It's up to you/your organization to decide how to work.
In the open source project that I run (20 years, 75+ developers over time, 400-500k LOC) we all have a clear understanding of (e.g.) whether to merge or rebase. On the odd occasions that there's a lack of clarity, it's normally a great sign that it doesn't matter.
The fact the you would be asking those questions suggests to me that the necessary policy-level decisions have not been made (or have not been made clear).
For most unitary organizations, some of the options that git gives you make no sense at all. That doesn't mean git should change, it means that it's not a great tool for unitary organizations.
Note that some of the choices (e.g. stash vs commit) are choices that each dev has to make individually, and some are pure incidental complexity.
`ls` wouldn't be better if I had to pass a flag to see the output as today, and another flag to print one character per line, and another flag to print each character in a different color etc. (even though that would give me 'more freedom').
Part of the problem is that Git, to make it manageable, requires all of these types of concerns and decisions to be addressed, and secondly, it has somehow become the only standard that people have even heard of. There isn't even a decision about which system to use anymore.
Having used both, I still prefer Perforce over Git. And if it were up to me, I would take a step back and investigate other offerings like Plastic SCM. But trying to make these decisions is nearly impossible now that Git is treated as a given.
Also, file locks are awesome if you're working with binary files (a thing that P4, unlike Git, can actually do), or even when doing a big refactoring that you know will cause conflicts with any other change. Otherwise, at least on our server, we very rarely used them (ignoring the temporary lock just as you're submitting code).
I'm not sure what you mean about rebasing. The basic P4 workflow is equivalent to `git pull --rebase`. In fact, it's pretty hard NOT to rebase in P4.
Also, why is your own branch useful actually? Nevermind your own repo? You can always just keep multiple copies of the code if you really want to.
Also, with P4 you don't have to cleanup your whole working set just to switch branch - it's just a `cd` away!
Of course, different strokes for different folks and all that.
I need to make more decisions because of its limitations (single repo or one repo per module? Or maybe use submodules somehow? With P4, we had a single repo with all of the code of the entire organization).
Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?
If I want to checkout a new branch while I have work in progress, do I commit it and later amend or revert, or do I stash it? Or do I rely on autostash?
Do I push directly to main, or do I rely on pull requests? Should those merge or squash commits?
I understand that all of these options and concepts make sense for distributed orgs, like the Linux kernel dev community and many other opensource projects. But I don't understand why so many traditional organizations are adopting Git. Its model is way too complex for the way normal orgs work (1 centralized server as the source of truth for the whole project), and it has serious limitations for anything which isn't pure code and isn't carefully curated.