But I’d go even further and say: svn isn’t even a good choice for a basic feature branch workflow. Not that it’s impossible, but the added “convenience” of svn is much smaller than the gains of git.
I don’t think the “D” in dvcs is important. As you point out, most people use git with a blessed central repo because that’s what we want.
For SVN, we mostly had long-lived "release" branches. Things like pre-merge code reviews were very hard. If you wanted to send some incomplete code, you sent an email with . tar.gz file attached.
With GHE, everyone makes branches all the time. It works great for code sharing or review. And there are unique advantages too, like an ability to run a distributed set of tests on arbitrary unmerged fork/branch, which rely on branches being very cheap.
SVN has 3 way merge too so this isn’t the issue it was in other VCS’s
>> The problem is all the drawbacks of trunk based development
Those were all addressed reasonably well by about 2014, e.g. upsource (my preference by far) or crucible. TeamCity’s merge after private build feature etc.
Ironically these days i see a big push to use git in a way that would work pretty well in svn too.
The biggest hassle with svn was long lived branches. Back then we encouraged devs to branch and then somehow smoosh it all back together (painful). Then we said ok do it more frequently in atomic commits (i liked that model) then DVCS took off largely in the open source world and now major dev houses (well i guess except google with p4 - but they do provide a git interface) all have come along for the ride.
Ironically with products like Stash/Bitbucket and Github Enterprise, we’re back to an SVN like model.