So kannst du dir bei Git etwa niemals sicher sein, daß das, wie sich dir die Historie darstellt, auch die Wahrheit ist - denn Git bietet die Möglichkeit, aus dem, was war, das zu machen, was „hätte sein sollen“. Manche Leute sehen das als ein Anti-Feature an.

Falsch, wenn Du einmal etwas in git committed und gepushed hast, kann es ohne git push -f nicht mehr geändert werden. Und -f kann man leicht serverseitig verbieten.
Und serverseitig kann die Geschichte auch mit SVN umgeschrieben werden:
http://oliverguenther.de/2016/01/rewriting-subversion-history/
Der einzige Unterschied ist hier also, dass git es einfach macht, die Geschichte umzuschreiben, wenn das denn gewünscht ist. Verhindern kann man es mit beiden Systemen.

Git unterstützt keine VCS-IDs, während Subversion dies tut (wenn Du das doch mit Git hinbekommen solltest, sag Bescheid - es gibt Leute, die vermutlich einen Freudenschrei ausstoßen werden).

Was soll das überhaupt sein? Keywords, also solcher Kram wie $Id$? Das ist ohnehin eine beknackte Idee. Die Aufgabe eines VCS ist es, Quellcode zu verwalten, nicht irgendwelche Variablen irgendwo einzusetzen.

Manch einer macht geltend, daß Git eigentlich gar kein Versionskontrollsystem sei, sondern ein Werkzeug zur verteilten Zusammenarbeit. Und tatsächlich: Schaut man mit Git ins Repo-Log, sieht man gar keine Versionen/Revisionen, sondern nur Hashes. Subversion hat hier den Vorteil, numerisch vorzugehen.

Wenn man eine Version kennzeichnen will, setzt man dafür einen Tag. Revisionen zu zählen bringt keinerlei echte Vorteile.

Aber diese arrogante Aussage „es gibt keinen Grund mehr, Subversion zu verwenden“, geht mir dann doch gegen den Strich.

Ist mir ehrlich gesagt egal, ob Du mich für arrogant hältst. Ich habe in dieser Sache schlicht recht, und Du weißt das auch