SVN ne permet pas de réécrire l'histoire.

Ca, c'est un vilain défaut. Très vite, je n'ai plus pu me passer de la réécriture d'historique intégrée de Git, pour un historique des commits plus linéaire et plus facile à bisecter. On s'en fout de tous les commits incomplets et buggés qu'on a fait lors du développement (des conneries, on en fait toujours). Si on peut réécrire pour faire un truc propre avant de diffuser, c'est une feature importante
Réécrire les branches remote sur un repository public, c'est largement considéré comme très vilain, pour des raisons en général bonnes.
Quand on n'a pas la réécriture d'historique, il faut avoir recours à plusieurs outils (quilt + SVN, par exemple) plutôt qu'un seul (Git).

Je me suis déjà fait des putains de frayeurs avec GIT avec un rebase qui s'est mal passé, et une perte de plus de 100 commits dans une branche ! (J'ai finalement réussi à réparer la branche, mais avec SVN j'aurai pas eu à le faire).

Forcément, traditionnellement, SVN ne sait pas rebaser, et de plus, son merge est moins malin que celui de Git, même s'il est amélioré au fil du temps ^^
Mais sinon, je compatis, bien que je ne me sois pas trouvé dans la situation d'avoir à faire ce genre de réparations. Je n'ai pas non plus eu des branches aussi longues par rapport à une branche principale qui évolue en parallèle, seulement jusqu'à ~25 commits.

SVN supporte les répertoires vides.

C'est un fait, mais le contournement de cette absence de support par Git (qui s'explique par des raisons semi-techniques) n'est quand même pas difficile
Le fichier placeholder peut d'ailleurs très bien être un .gitignore, comme dit plus haut.

SVN support la gestion de conf de fichiers binaires.

On peut bien entendu mettre des fichiers binaires dans Git, mais c'est connu que Git (seul) n'est pas le plus doué pour leur gestion, en effet.