Tja vermutlich, weil es einfach genau für diesen Zweck entwickelt (spezifiziert) wurde. Generell hat sich OSGi in diesem Bereich auch neben JEE platziert ob man es wahrhaben will oder nicht.
OSGi hat eine ziemlich steile Lernkurve, das mag sein - was aber besonders an dem Export-Sichtbarkeitslevel liegt) aber wenn man erstmal drin ist, funktioniert es ohne Probleme. Am Anfang war es schwer OSGi fähige JARs zu finden (außer in der Eclipse-Welt, daher bin ich hier auch oft mit Leuten aneinander geraten, welche der Meinung waren "alles klein Problem", klar in der Eclipse-Welt ;-)) aber mittlerweile ist die Situation anders und die meisten OSS Projekte stellen OSGi fähige Bundles (java.net Projekte sind oftmals Ausnahmen).
Da aber fast alle JEE Application Server auf OSGi (z.B. Glassfish) wird auch hier die Situation immer besser.
Zu deiner Frage:
Du könntest Equinox nehmen (Eclipse), dies ist die Referenzimplementierung mit allen Features. Du kannst aber auch Apache Felix nehmen, der hängt immer kurz der Spec hinterher kann aber auch alles. Ansonsten gibt es noch Knopflerfish, damit habe ich selbst noch nicht gearbeitet, kann also nichts dazu sagen. Weiterhin gibt es noch einen ganzen Batzen an kommerziellen Implementierungen (ProSyst, eine von Samsung, ähm ka was noch) und auch so neben den drei schon genannten OSS Implementierungen weitere wie Concierge, Native-OSGi (implementiert in C++, noch nie mit gearbeitet) und Jadabs für Kleingeräte (glaube diese Impl ist nicht vollständig)
Welche Vor-/Nachteile die Implementierungen bringen ist eigentlich ziemlich sinnfrei, da sie eine Implementierung der OSGi Spec darstellen, ergo sind proprietäre Erweiterungen vielleicht ganz nett, stehen aber der eigentlichen Idee einer Spec (der Portierbarkeit) irgendwie im Weg.
OSGi bietet mir genau das was ich brauche wenn ich ein dynamisches System (Module hinzufügen, Module entfernen, Module aktualisieren, Module neustarten, Abhängigkeiten unterhalb von Modulen, einzelne Modul-Sandboxen, ....) benötige. Natürlich kannst du dir die Spec nehmen und eine entsprechende Implementierung selber entwickeln aber ich bin sicher, dass du schnell aufgeben wirst und entweder dein halbes OSGi nutzt oder eine der bestehenden Implementierungen nimmst. Die OSGi Spec ist an einigen Stellen / Features schon tricky und das ist keine "och das mach ich mal an einem Wochenende"-Aktion. Im Gegensatz dazu kann man den ServiceLoader und sein Prinzip in einer Stunde selbst nachbasteln.
Gerade die neueren OSGi Specs wie Blueprint bringen ein komplettes, Modul-übergreifendes Dependency Injection System mit welchen durch Spring (und Spring DM) inspiriert und großteils auch von SpringSource spezifiziert wurde.
Weiterhin bekommst du in jeder OSGi Runtime (Equinox, Felix, Knopflerfish oder dem ganzen Haufen der kommerziellen Runtimes - auch für Android) automatisch Configuration Management, Event System, einen Preferences Service, das komplette Bundle (Module) Management, User Service, erweiterte Sichtbarkeitsebenen, usw geschenkt. OSGi geht also weit über ein einfaches Modulsystem hinaus.
Ich habe mich auch lange gegen OSGi gewährt aber dieses komplette System selbst zu implementieren ist schwachsinn und sollte niemandem ernsthaft ans Herz gelegt werden.