Hardly, I spent a lot of time in spaces where Java and others languages would be considered. If there was ever any hint if performance being a bottleneck we chose C++ over it. Even moreso because unsafe doesnt exist on some variants(Android).
What unsafe gets you is good cache usage. JNI and other approches negate that benefit(also disables inlining and other things).
We just have different experiences, as in a lot of shops I was in, performance was not the primary factor in language choice, but it could be its primary detractor of course if poor. Rarely did we ever find the bottleneck of the language the issue, and we dropped into JNI as needed (or more often reworked away from our original assumptions). I would say the majority of Java's success came from these kinds of shops, and the ones where performance made so much of a difference you would abandon the language altogether, I still doubt unsafe saved that abandonment from happening.
This is not to say Unsafe was not appreciated by lots of places, esp wrt high performance libs, embedded dev, HFT shops, etc. But I don't believe that Unsafe really affected success/popularity of the language, heck, it's not even the most important pert of the performance story around the success/popularity of the language not to mention all the other non-performance-related aspects that really did affect its success.
Not denying that Java is/was popular, just that it's popularity was curbed by the lack of value types, direct memory allocation(unsafe) and a few other performance sensitive features.
The same reason that you see Unity dominate the game space is that the native interop and cache usage story is much clearer.
FWIW JNI is not a silver bullet to performance problems by any means. The actual overhead of the JNI call either into or out of the VM is non-trivial and usually evicted whatever cache line you were touching. For things that are performance critical you'd usually see a drop of 10-50x between mixed JNI and code that was more cache aware but did the same work(in C++/C/C#).
The irony here is that although C# has had direct memory and structs available for ages, Unity never took advantage of that - until just now - the in-development ECS / C# Jobs / Burst compiler architecture is utilising packed structs and manual memory allocation heavily. Why I say this is ironic is that Unity/C# have succeeded despite not using these features that you claim curb Java's popularity in the same space
What unsafe gets you is good cache usage. JNI and other approches negate that benefit(also disables inlining and other things).