I think it's a different problem. Software engineering is fundamentally about the management of complexity. People who have only worked on small programs -- like most non-software engineers and scientists -- don't understand the need to manage complexity because they've never worked on any program large enough to require it. Programming in the small is easy, particularly when you're mostly doing numerics. Other engineers see that and think that all programming must be easy.
Ideally you want something that is both deterministic (i.e., it's not running randomly in the background like a traditional GC) and that guarantees there are no leaks. In theory ARC gives you both of these.
In fact, I'd go so far as to say latency isn't the issue - the issue is that typically GC'd languages rely heavily on heap allocation because it's cheaper(!) not more expensive. Put another way: java creates lots of garbage, C/C++ does not.
If you wrote a C/C++ program that allocated as heavily as a typical java program... well, I'd expect performance issues that would probably be worse than java's.
> java creates lots of garbage, C/C++ does not.
Properly written C/C++ does not. Badly written C/C++ creates garbage (leaks memory), and it can never be recovered, because there's no GC. The solution isn't GC, though - it's to pay more attention to who owns the memory.
I mean to say, most people here will be highly familiar with version control, but back in the days when I used to audit companies, version control was barely[1] used, and editing files on the live server was the norm. And even here we're still having discussions about how "hard" it is to manage dependencies, use strong typing, use safe languages, garbage collection, bounds checking, formal proofs, etc.
[1] I think I may be correct in saying never used. I can't recall a case where we saw a company using any kind of VCS, but perhaps I just forgot.