What are good reasons to use trunk-based dev, as opposed to release branch to release branch?

[David Karr <davidmichaelkarr@gmail.com>]

Personally, I always use trunk-based development.  New changes go into
feature branches from master, and are merged to master after approval.
When we're ready to make a release, we create the release branch from
master, very few changes go into the release branch after we cut it.
Any changes that have to go into the release branch are first merged
to master, and then cherry-picked to the release branch.

My team maintains the "platform" for a large number of
similarly-constructed microservices. That includes the build process,
foundation libraries, and some development guidance to the teams
developing those services. We advise using trunk-based development,
but it's up to each team what they actually do.  I recently heard of
some teams doing what I would roughly call "release-to-release"
development, which means at some point in the distant past they
created a release branch from master, and then the next release they
cut from that release branch, ad infinitum.

What bothers me is that although I know this practice is wrong, I
don't think I can fully and completely describe why it is wrong, and
why TBE is better.

At a minimum, I know that with TBE, someone with no knowledge of the
repository can look at the master branch and know that represents the
latest work on the repository.

I can't very argue that their practice results in "merge hell" when
merging to master, because they never actually do that.

Can someone describe the flaws in this roughly named
"release-to-release" strategy, and why TBE is better?