Git was designed to be used in a decentralized fashion, and as such has a lot of additional logic steps to deal with this.
The way people use git today only with centralized storage such as github makes it a inferior solution compared to SVN

I'm not familiar with SVN but I've never had a problem with Git's logic. Having a near-completely independent local copy is very useful even if collaboration only happens through branches of a central repository.

Also, I'm not sure how you interpret the word but the Github workflow is most certainly decentralised, with all collaboration happening through PRs and forks, where private forks can often become separately released variants distinguished by a single patch if the patch is rejected but the author still wants to use it.

@lbfalvy git/github for open source seems niece due to the forks and all that.
For closed source projects, you won't need forks anyway

Alone the ability to merge branches is superior to SVN.

Utter tosh. You can argue SVN is *simpler* on the basis that it's less capable and has fewer features - that's about it. It's inferior in almost every way.

You can't even (sanely) create something as simple as a pull request with SVN, you can't bisect, you can't use anything that relies on branching like feature branches or release management, you can't commit locally and clean up your commit history before pushing... the list goes on.

The only devs who still love SVN and proclaim it as the best thing to use are, in my experience, those who can't be arsed to learn git. Get with the times, it's the de facto VCS of choice. You need to understand it to be effective in almost any dev role these days.