One of the peculiarity of Pharo (and Smalltalk) is that when you shutdown the system, you can persist the whole system on disk (called "the image"). Next time you open it, you start exactly where you left.
All the development tools are mixed with your code. There is no differences between the coding time and runtime (i.e., you code at runtime). If you are familiar with IRB in Ruby, imagine a GUI running in IRB.
This means that it is hard to see the limit between your code and Pharo's code. Pharo 7 seems to bring a bootstrap process where you can build images from scratch. This is an interesting evolution that will vastly improve the development/reproducability/deployment story.
Please don't complain about downvotes, especially not within the first 23 minutes. It's common to receive one random downvote and a couple more piling on, but given a few hours a decent comment will be back in the black.
As far as I understand it: it doesn't necessarily compile in that sense. You are constructing an 'image', which is basically a living environment that your program runs in, and maybe it corresponds somewhat to a VM. But you're not really treating the code that the VM runs as separate to the VM itself.
In some sense I think you might map it to something like a Lisp machine, where you can interact with a running program and its state through a REPL.
Someone more knowledgeable might be able to elaborate on that (or correct the misunderstandings), but it felt worth offering something other than a straight up dismissal of your question.
This is indeed similar to Common Lisp and Emacs.
Back to the original question: the VM runs on Windows/Mac/Linux and on some IoT devices. The code is compiled to bytecode which can then be JIT compiled further on some architectures/OSes. The compiler and the whole infrastructure is exposed and available on runtime.
Pharo has classes for easy FFI to C and for bundling native libraries. I don't know if it's possible to call back from C to Pharo, but I assume yes (many libraries require this). There is no FFI or other integration with any other language (at least as a built-in, there are RPC interfaces for some langs as add-on packages).
As for "standalone binaries" - almost, as you need to bundle the VM with the image; there are some helper scripts for bundling and then launching images.
The most obvious use case is GUI programming, there's also old-school Web programming with Seaside, data crunching and visualization with Roassal. Other than these killer-apps, Pharo is just as capable as any other high-level language, although with a much smaller selection of libraries available.
Another difference might be that most image-based Common Lisp implementations don't use portable byte-code. Some are using byte-code engines, but those are usually not portable across operating systems and/or machine architectures.
But, about the GUI, I was thinking about Morphic. It's basically a GUI designer on its own: you can create widgets by instantiating their objects in Playground. It doesn't matter what widget it is: you can create a button or a list item or a textarea on their own. You can then edit them with halo actions or in the inspector until they look like you want, then add them to container widgets, then finally put them in a window. It's bottom-up programming for GUIs! You need to manually track the changes you make via inspector (ie. to copy them to playground), but if you do, you can copy the whole playground into a method and done, you've just designed a GUI app! You later replace some Widgets with their subclasses written by you to handle events and you're done.
EDIT: Nope! I was wrong, see comment below. It promises Arduino support but via some firmware with Pharo itself still running on the desktop.
Does it compile to other platforms? Binary code, compile to C, to LLVM? Does it compile to other VMs like Java and it is compatible with javascript engines? For me this is a basic aspect of a language.