Jak dla mnie największym wrogiem C++ są uczelnie i kursy, cały czas uczące C++ z poprzedniego tysiąclecia. Nawet tutaj pierwszym strasznym słowem powiązanym z C++ były wskaźniki (choć to nie one są bezpośrednio problemem, a ich arytmetyka i losowe powiązanie do czasu życia zmiennych).
Dość zauważyć, że twórcy Javy wykorzystali ten negatywny PR i zmienili swoją nomenklaturę z wskaźników na referencje (ale jakimś cudem zapominając o NullPointerException).
W nowoczesnym C++ (czyli prawie od dekady już) nie ma żadnej potrzeby, aby wskaźników używać jako czegokolwiek innego niż obserwatorów (co zresztą pięknie pokazuje zalinkowana wyżej prelekcja Herba Suttera), cały ten cyrk z zarządzaniem pamięcią został już imo rozwiązany. Jeśli piszesz nowy kod - piszesz go bez problemów. Jak używasz starych bibliotek, to ich używasz zgodnie z ich API. W środku mogą mieć stary kod i ewentualne memleaki, ale to nie jest zadanie dla użytkownika biblioteki.
Co do ARC vs. GC: pewnie, GC jest często lepszy. Tylko z mojego doświadczenia (t.j. w branżach w których robiłem), był to zawsze problem bardzo mało znaczący. Jeśli chciałem przekazywać immutable dane wątkom, to przekazywałem je przez nagi wskaźnik/referencję, a czasem życia zarządzał odpowiedni manager (najczęściej po prostu dawałem wskaźnik do obiektu "na stosie", który znikał po joinie na wątkach), albo były to po prostu stałe globalne. Zdarzyło mi się kilka razy przekazywać shared_ptr
z danymi między podsystemami, ale względem czasu ich życia, kilka atomowych operacji na refcountach wydaje się kompletnie bez znaczenia.
W każdym razie: poznać C++ na wysokim poziomie jest trudno, trzeba naprawdę się postarać. Nie znam żadnego innego języka na takim poziomie, więc nie mogę się z pewnością się wypowiadać, ale wydaje mi się, że inne języki też mają mnóstwo smaczków, o których trzeba wiedzieć; tylko może mają ich trochę mniej. Z drugiej strony, nie uważam, aby obecny C++ był zbyt trudny do użycia w zakresie niezbędnym do jego użycia w większości zastosowań.
Co do wydajności: uważam, że w większości zastosowań nie ma tak dużego znaczenia, jak się to przypisuje. Moja aplikacja zarządzająca w czasie rzeczywistym tysiącami pojemników w magazynie automatycznym, w którym pracowało kilkuset ludzi, a pojemnik mógł jechać po rolkach prawie 5 km zanim trafił gdzieś gdzie był, zajmowała ok 20MB RAM-u, i średnio 0% czasu pracy procesora, oferując czasy reakcji na poziomie 1ms. Nie optymalizowałem jej jakoś przesadnie, a dla ułatwienia kodowania wykorzystałem framework Qt. Jestem przekonany, że w Javie, C# lub D bym mógł osiągnąć podobny wynik (no, poza RAM-em), a największym ewentualnym problemem by była skalowalność i złożoność obliczeniowa zastosowanych algorytmów, a nie cokolwiek innego. Tak samo widzę to w prawie każdej innej branży poza dość specyficznymi wyjątkami (gamedev czy pisanie kerneli).
TL;DR: nie widzę powodu aby nowoczesnego C++ nie wybierać w projektach. Ale też nie widzę specjalnego powodu, aby go wybierać.