Erstmal herzlichen Dank für eine derart ausführliche Antwort!
Bei dem Projekt, in dem der Wunsch nach einem Repository Manager aufkam, verwende ich gradle. Daher versuche ich meinen Beitrag konzeptuell zu halten.
Der Wunsch kam deshalb auf, weil ich ein Artefakt erstellen muss / möchte, das ein anderes Projekt erweitert. Konkret geht es um eine winzige Erweiterung der Templateengine Thymeleaf, die unabhängig vom Hauptprojekt ist. Deshalb möchte ich sie nicht in dem (multiproject-)build einfügen, auch wenn es dort nur eine „interne“ Abhängigkeit wäre.
Denn ich kann mir vorstellen, dass diese Erweiterung auch in anderen Projekten relevant sein könnte.
Das Plugin für artifactory / TeamCity habe ich gestern auch schon gefunden und installiert. Einen echten Mehrwert gegenüber dem gradle-Plugin habe ich nicht direkt gesehen. Prinzipiell unterstützt gradle natürlich auch das „Standarddeployment“ von maven (siehe hier).
Allerdings, und jetzt bin ich wieder konzeptuell, stellt sich mir die Frage, wo die richtige Stelle im Build ist, um die Artefakte zu deployen. Gehört das in die Build-Konfiguration oder in den CI-Server? Ich hätte jetzt nämlich eigentlich gedacht, dass es besser in die Konfiguration vom CI-Server passen würde. Das hält das Buildfile frei von Infrastruktur (keine fest hinterlegten Server). Die Effizienz beim Deployment halte ich vorerst für sekundär.
Der Vorteil bei Nexus keine MySQL-Datenbank zu benötigen kommt bei mir nicht wirklich zum Tragen, weil ich für den CI-Server, für das Projekt selbst und auch mehrere andere mehr oder minder große Projekte einen MySQL-Server administriere. Ich war bei der Installation sogar ausnahmsweise mal vorausschauend genug, um den MySQL-Connector schon vorher in das richtige Verzeichnis zu kopieren und die manuelle Konfiguration gem. Dokumentation vorzunehmen 
Deine Ausführungen zu SNAPSHOTs sind plausibel und ich verwende bisher auch keine. (Ok, zugegebenermaßen gerade in diesem Moment verwende ich einen Spring 4.2 Snapshot, weil dort ein neues Feature implementiert wurde, das ich mir in einem JIRA Issue „gewünscht“ hatte. Das ist aber nur testweise, bis es in zwei (?) Wochen den ersten RC gibt.)
Bei selbst deployten SNAPSHOTs ist die Problematik denke ich mal deutlich weniger kritisch - dort habe ich ja alles selbst in der Hand. Sobald es einen stabilen Zustand gibt, kann ich dann ja intern auch releasen.
Zum Thema „frei von Infrastruktur“ hatte ich gestern auch noch die Überlegungen, ob ich den artifactory überhaupt als Proxy nutzen soll oder ob ich dort nur die selbst deployten Artefakte zwischenlagere. Du hast im Abschnitt ab „Ansonsten:“ geschrieben, dass man das aber genau nicht machen soll.
Der Grund dafür ist wahrscheinlich, dass man dadurch alles unter eigener Kontrolle hat und somit der Build nicht brechen kann, wenn ein fremdes Repo mal nicht erreichbar ist.
Bei meinem Hauptprojekt ist es so, dass ich vielleicht wirklich den eigenen Repo Manager als einziges Repository eintragen kann. Bei der Erweiterung von Thymeleaf hingegen könnte ich mir vorstellen, sie open source zur Verfügung zu stellen. Da wäre es dann wohl sinnvoll, das Deployment so zu konfigurieren, dass die Artefakte in einem öffentlichen Repo landen und die eigenen Abhängigkeiten aus maven central geholt werden, oder?
