First of all, not being compiled and being interpreted (what he surely meant by scripted, which is somewhat vague and used for different purposes anyway) are different sides of the same coin, and thus really the same reason.
The last reason, that it doesn't run on every platform, is just confusing. It sounds like he's trying to tout Java's portability and PHP simply isn't Java. However, Java runs on one very specific platform: the JVM. That platform in turn runs on many other platforms, and thus gives Java its portability, but it's not quite the same as the traditional use of "portable". For example, C is portable and runs on everything from a PDP-11 to the latest embedded devices.
However, C does that by specifying rules of its own abstract platform, and compilers transform C code into assembly according to those rules. This is how Java's portability is similar to C's: they both define rules which are translated into instructions for a specific, concrete machine (processor); the difference is when that occurs.
All problems in computer science can be solved with another level of indirection.
— David Wheeler
In reality, even assembly or "machine code" is interpreted by the processor into its native actions. (I don't have a good source at hand for this, but I recall that it's lightly covered by A Crash Course in Modern Hardware, which is a good presentation anyway.) As processor speeds get faster, we hardly notice on our underused boxes whether a given program is in asm or run through an interpreter, but this is where the definition of "real programming language" comes into play.
The only sensible way to define a "real programming language" is as "a language to get real work done", but that really punts on the definition of "real", too. (It does, however, establish a distinction with esoteric programming languages, because nobody does real work, for example, in Malbolge, for any definition of "real" you could get ten people to agree upon.) And, compared to today, your choices of a programming language were much more limited by their implementation strategy and overhead (e.g. a runtime interpreter) in the past. However, even today, some languages are more "real" than others for certain applications and expected loads, it all depends on your requirements.
It sounds like your teacher has only experienced PHP through toy web applications (and maybe using 'application' is a stretch for what he's seen). Toy programs aren't real work. PHP definitely has a lot of problems, but I could not say it isn't a real programming language, except in jest.
Debugging is anticipated with distaste, performed with reluctance, and bragged about forever.
— Dan Kaminsky
There is a certain association of "real" with "hard to do" (related to "real work") and your teacher may have been expressing this sentiment. This has always appeared to me as a form of bikeshedding (there's a better term for this exactly, but I can't remember it), where one's estimation of the value of a thing is related to the effort one had to put into it (e.g. a bikeshed is more important when I provided input on the color of the roof and whether it should have a sign). We intrinsically value our own effort more than that of others – just because we're familiar with it, if for no other reason – even when it doesn't make sense to do so. PHP, despite its faults, does make some things easy, and it and programs written in it can consequently be perceived as worth less.
