Sure it's a true statement. Even if you have to compile to different targets (and you do), that's much simpler than implementing shared dependencies on those different targets. When you deploy a binary with no external dependencies, you can (generally) set it and forget it.
It's not to say there aren't meaningful differences across targets you need to account for, but it is "just easier" in my experience.
So, it's not a function of compiled vs interpreted. It's about a single binary vs shared resources.
So while you can't get a single binary with an interpreted language (you need the shared runtime), however you can also get shared libs using a compiled language.
I've found doing cross platform development using NodeJS significantly easier than using C++ (of course I had to use compilers that didn't default to IEEE 764).
Minor nit pick, but theses days "interpreted" languages are also compiled. What we are really taking about is AOT vs JIT (though even here, there are AOT compiled languages that still require a supporting run time environment installed, such as Java)
Not that unusual these days. CPython supports a similar intermediate binary (.pyo) and .NET does the same too, albeit the bytecode is shipped inside a PE.
And you can't even get that from the language itself. While MRI (last I checked) doesn't support an intermediate file of its bytecode format, Rubinius does (.rbc), for example.
> So while you can't get a single binary with an interpreted language (you need the shared runtime)
Offtopic nitpick: of course you can, just combine the runtime with the code and wrap it all in a single executable. E.g. http://www.py2exe.org does exactly this.
How is this a true statement? Ease of distribution isn't a function of a language's runtime environment (native vs interpreter).