A binary program is stored in form of instructions on the hard drive. Usually, when you execute the program, it is copied into RAM, because that is a lot faster to read and write than your hard disk (though currently, companies try to close that gap with NVMe SSDs). But sometimes, especially on embedded devices, there isn't a lot of RAM available. So instead of cluttering your RAM with a copy of the program, the operating system starts reading the program directly from the storage. Though the binary is on your hard drive, the application heap and stack (for your variables and pointers) can still be created in memory .

The usual computation cycle is

storage -> ram -> register -> cache -> ram -> storage

it changes to

storage -> register -> cache -> storage

so there will be more instructions since we don't use the RAM.

as an example with a fictional CPU just to get the difference impact

1 Cycle is 1 Hertz (obviously)

-> l1 cache takes ~16 cycles

-> l2 cache takes ~32 cycles

-> l3 cache takes ~48 cycles

-> ram takes ~256 cycles

-> hd takes ~5012 cycles

so accessing things directly from the HD should be small because they are rather slow in comparison.

but if you got limited RAM for example and enough small programs this can be a good solution or if time is not really relevant for certain processes.

The usual idea (obviously) is that "preloading" all the information into the RAM to increase the overall performance. But maybe you don't need it at all and in the end you even save cycles by not using the RAM as buffer.

It's as so often -> time vs space and in this case space is critical so we trade against time.

Edit:

i forgot one classic / important use-case -> isolation of a program if you use an usb-stick for example you can "trap" the program inside the Stick and just use the CPU of the computer