Sometimes it's ok to work like this, but you asking git not being judgamental is like saying your roomba should accomodate to you didin't asking you to empty it's dust bag.
I had a branch that lived for more than a year, ended up with 800+ commits on it. I rebased along the way, and the predictably the final merge was smooth and easy.
I rebase often myself, but I don’t understand the logic here.
2) small conflicts when rebasing the long lived branch on the main branch
if instead I delayed any rebasing until the long lived branch was done, I'd have no idea of the scale of the conflicts, and the task could be very, very different.
Granted, in some cases there would be no or very few conflicts, and then both approaches (long-lived branch with or without rebases along the way) would be similar.
"If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases."
There is _everything_ to remember. You no longer have the context of what commits (on both sides) actually caused the conflicts, you just have the tip of your branch diffed against the tip of main.
"Hence I don’t understand the benefit of the latter in terms of avoiding conflicts."
You don't avoid conflicts, but you move them from the future to the present. If main is changing frequently, the conflicts are going be unavoidable. Why would you want to wait to resolve them all at once at the very end? When you could be resolving them as they happen, with all the context of the surrounding commits readily at hand. Letting the conflicts accumulate to be dealt with at the end with very little context just sounds terrifyingly inefficient.
It's just like doing merges _from_ main during the lifetime of the branch. If you don't do any, you'll likely have lots of conflicts on the final merge. If you do it a lot, the final merge will go smooth, but your history will be pretzels all the way down.
In other words, frequent rebasing from main moves any conflicts from the future to "right now", but keeps the history nice and linear, on both sides!
And of course, making it easier to rebase makes it more likely I will do it frequently.
I always do long lived feature branches, and rarely have issues. When I hear people complain about it, I question their workflow/competence.
Lots of commits is good. The thing I liked about mercurial is you could squash, while still keeping the individual commits. And this is also why I like jj - you get to keep the individual commits while eliminating the noise it produces.
Lots of commits isn't inherently bad. Git is.