Java's startup cost means that you'll usually leave the process around and serve requests through that single process (the typical "application server" model). PHP's startup cost is extremely low, and the standard setup is to simply toss more instances of apache at the problem. As traffic increases, add more servers. It's pretty much infinitely scalable.
Fast garbage collection is meaningless when you simply toss away the entire app context at the end of the request (the way that you build PHP apps). PHP's garbage collection is actually pretty terrible, but it doesn't matter because you just toss it all out at the end of the request.
JIT compilation does not make a web app faster. It can (theoretically) help improve the speed of a desktop app or server process. In practice, it usually performs worse than statically compiled apps (e.g. C). Web apps startup and tear down every request in the PHP model, so it doesn't matter.
PHP's interpreter does not use less memory that a VM for java.
In most instances it does. A typical command-line PHP app uses about 4 MB of RAM. An apache thread running the PHP interpreter will usually eat 6-12MB.
Java as a language runs...much faster than php does.
Maybe in an alternate universe? But certainly not this one.
How to scale PHP:
Install app on more servers.
I work with PHP code every day that deals with hundreds of requests per second. The scalability problems are always on the database end, not on the application end. If you want the app to handle a heavier load, you simply add more hardware 99% of the time. You can't just throw more hardware at a java app to solve the scalability problem. No, PHP isn't made out of magic and butterflies, but this is one area that scripting languages really shine.
The idea that PHP's type hinting in some way makes apps harder or that it's a problem is just laughable. Dynamically typed languages have many advantages that statically typed ones do not. Data type indicates absolutely nothing about a variable. Use sensible variable names and document your code or it'll be hard to use. Forcing something as archaic as static typing on web development slows development cycles painfully.
No, PHP is never going to be good as a daemon process. That's just cold hard truth. PHP excels as a web app language and as a general-purpose scripting language. It can replace perl for everything and everything else for web apps, but it'll never replace C when it comes to high performance daemon processes. Nobody's ever going to write a web server in PHP.
EVERY language is "compiled". The difference is with regards to what it's compiled to.
Java is compiled to java byte code which the JRE maps to machine instructions to perform tasks.
PHP is compiled to PHP byte code which the PHP runtime maps to machine instructions to perform tasks.
C code is compiled to machine instructions to perform tasks.
C# code is compiled to CLI bytecode which the .net (or mono, or whatever) runtime (CLR) maps to machine instructions to perform tasks.
What affects speed is when that compilation occurs. In PHP, compilation is done at run time (unless you're using an opcode cache). In other languages, it's done at build time.
You can't really do the same in PHP, although you can use things like memcached to do some of them.