Okay, let's make one thing clear - I am not saying that Java programs are always faster than C++ programs or any such thing. I am saying, correctly, that there are technical reasons why there are circumstances in which Java can outperform C++. Over the course of a large complex program these benefits will almost always be outweighed by the disadvantages. I'll address your points one by one:
1. "1. Java is faster than C/C++?! Citation fucking needed. Any time Java meets or exceeds C/C++ for speed is probably because the library that the Java program is leveraging is an extremely optimized, pre-compiled, native binary... probably written in C/C++."
Incorrect. When Java is faster than C++ it's because it compiles with more context than a C++ application does when it is compiled. This allows for things like better virtual function inlining and subsequently things like better loop vectorisation. Again, this has to be taken in context, this does not mean that these optimisations that Java can make but C++ can not always make Java faster, that's absolutely false, but in practice it does mean that contrary to the common myth that Java performance is abysmal that performance has in the last decade rapidly approached (and again, in specific circumstances, surpassed) C++ performance.
2. "2. JIT compilation doesn't magically transform inherently slow semantics into super-fast-omg-native-speeds. Guess what? New'ing up a bunch of objects, destroying them, checking the bounds on every array, boxing and unboxing, pausing everything to run a garbage collect, using linked lists instead of arrays, and other similar abuses of memory and cache are fucking slow. Guess what Java does a lot of? You can pull the same stupidity in C or C++, but at least there's the option not to."
You are partly right here, and partly wrong. Some of the issues you cite are reasons why, in practice, large Java applications rarely perform as well as C++ counterparts, but you are also partly wrong - a number of the things you cite are either not issues, or are regularly optimised away by the compiler in practice. The garbage collector is indeed an issue that is the bane of obtaining deterministic performance with Java, but it's not a beast that is impossible to tame, which is why Java has had many successful applications to HPC tasks.
"3. "Well just write your Java program with memory stuff in mind." So... write it like C++ and STILL pay the penalty of the GC kicking in at random times and trashing your frame rate? No thanks. There's a reason engines like Unreal, Crytek, and id's are all written in C++: they write their own stuff to handle memory in an efficient fashion instead of a random stop-everything-while-I-clean-this-mess-up GC."
Sure, and there's a reason indies are almost entirely using JIT'd languages like Java and C# through tools and frameworks such as Unity and MonoGame - because when you're not going AAA then these types of frameworks perform perfectly well for gaming as proven by so many brilliant indie games in recent years. I absolutely agree that if you're making the latest and greatest cutting edge 3D engine that is going to blow away people with it's visuals that you'll still want to do it in C++, but let's be clear - this isn't most game development, far and away most game development in recent years is being done with managed languages - even on mobile there is a massive slant towards things like Unity. Even big studios like Blizzard are using it sometimes for games like Hearthstone.
"4. Why pay the penalty of waiting while the JIT converts stuff to optimized machine code? Why not START with optimized machine code?"
Because there is an absolutely massive development overhead in doing so.
There are a lot of folk stuck in the past, believing that C++ is still the god language, the be all and end all that should be used for everything, just as there is an even smaller subset of folk who see those C++ zealots even as heathens and believe everything ever should be written in C, and I'm sure it goes all the way down the chain to the one guy in a basement of some office block somewhere that insists everything should be written in machine code directly.
But that's not the real world, the fact is that lines have become blurred, it's not so clear cut any more that the lower level you go the better performance you get, hell, this isn't even a new thing - in the early 90s you could always write C/Assembly that performed better than C++, but by the end of the 90s and start of the 00s this was no longer true, there were few assembly programmers with the level of talent required to write more efficient assembly than a C++ compiler could churn out. The same is happening now with managed languages - as the last decade has progressed it's become ever less clear that there is any tangible performance benefit in using C++ for many applications and that's why even the game development world, one of the most high performance of all consumer facing worlds of development has even started to stray away from C++. There absolutely are still places where C++ matters, and professionally, I know this for a fact, because I use C#, Java, and C++ primarily and as a software architect it's been up to me to make the call as to when it's time to use C++ - a call that I most certainly do make when it makes sense. The reality is though that the time and place for C++ has consistently declined over the years relative to other technologies.
Now you might not like this, it might offend you greatly, you may take great issue with it, but it is reality, and no amount of bitterness and language fanboyism will change it, so you can really just make a choice - either sit bitter, posting anonymously (presumably because you're embarrassed to put your name to something you deep down know you don't fully understand) about something that wont change because your viewpoint is based on a few various fundamental lacks of understanding of the nuances of the technologies in question, or get over it and embrace it like everyone else that's actually being productive in this constantly changing world.