I have the same experience! Trying to introduce the teams I've worked on to TBD and frequent releases, but they don't see any issue with long lived branches and infrequent releases
Probably because for most teams there isn't an issue. You only start to see the problems long term branches cause when you have multiple long-term branches in a single repo, and that only happens when your team is sufficiently big to be working on several big things at once or when your product is big enough to use a monorepo where devs on different teams work on the same parts at the same time.
If you're Google or Meta these are very obvious problems that you'll see causing issues regularly. If you're a team of 6 in a corporation or a SaaS then you'll be able to work on a branch for weeks and still be able to merge it without any big problems.
This is my main issue with TBD actually - it's a solution to a problem that few teams actually have. Throwing away a working process like gitflow when you won't see any real benefit doesn't seem like a great idea.
Gitflow solves a problem few teams actually have. Throwing away a working (simpler) process of having a single trunk when there's no real benefit doesn't seem like a great idea.
It seems to me that Gitflow just adds a lot of ceremony of keeping multiple branches somewhat in sync through merges left and right.
I'm fine with the argument of keeping existing processes because they work, whatever they are.
It's more efficient. Why prevent people from reviewing your commits and avoid merging until your feature is 100% complete? With TBD people on your team are able to review changes as they get completed and you can merge them in to avoid future confilcts and to allow others to benefit from your changes too.
It is made to have few long term release versions, say you're making a database and need to support customer being major version or two behind for some years.
But if you are just making app for a client you really need just "this is released as stable and running in prod" and some flavours of dev/test environment and that doesn't need much of model to work at all, just prod/test branch with features never landing directly on prod is good enough.
In the past I’ve felt a little strange that we don’t “modernize” to adopt TBD, but over doing this for many years with the same size team, it just seems unnecessary because we’re a small team.
Though those branches could be needed if you are doing mobile, desktop or library/framework development.
Or don't acknowledge, acummulate technical debt, because due to being late CR rarely results in any deeper changes in flawed code. Then complain that project is a mess, but management doesn't want to listen about refactoring.