In theory, if a program is written in a high-level language and you have a correct implementation (interpreter, compiler, runtime) of that language on a new system, then the program should be able to run there.

In practice, this is not always so straightforward, especially as you move closer to machine-level details or consider compiled binaries.

Many compiled programs are built for a specific architecture (x86, ARM, etc.). They won’t run on a different architecture unless you provide either: A cross-compiler (to generate new native code for that architecture), or an emulator (which mimics the old architecture on the new one)

Yes, but it might do something different there, such as print an error message and exit.

Based on the OP, I think the idea is that it's very easy to port this emulator to a new system.

You're right, it's technically true of any program, but it wouldn't necessarily be practical. Implementing CPython on a Gameboy Advance, for example, would be tedious and likely not entirely possible.

The purpose of Bedrock was to make a system that is easy to implement on as many computer systems as possible. I've got plans to make a working system from a 64KB RAM chip and a $2 PIC12F1572 8-bit microcontroller (2K memory, 6mW power, 8 pins), just to see how far down I can take it.

Not quite. Programs normally need to be compiled per system type, and sometimes per system, due to differences in the OSes' versions, APIs and hardware. The idea behind this type of emulator is that you need compile it only once, and the emulator takes care of those differences for you. The Bedrock program would always ‘see’ the same OS and hardware.

You've got it, yeah. It makes writing programs across different systems so much nicer, because you can just write your programs against a single tidy 'bedrock' abstraction of the file system, screen, networking, etc.

moreover, once "it can run anywhere" is defined, you can't run it anywhere

One-size-fits-all never fits everyone :)