That's an constrained example of the general concept of a file-association (having a file plus the info of what application executes that file).

As such, it predates UNIX, exist in other OSes as well, and can be even more dynamic (as shebangs are hardcoded into the file, where file + executable associations could be external).

Linux offers another way anyway: linux_binfmt

If I'm not mistaken that's also how jar files can be executed by themselves without calling java on them.

It is nifty and mind-blowing. It basically means there is a way to "call" a program-file and let it decide who should interpret the program.

It is not too different from the way in which html-pages can declare what is the character-set that should be used to interpret the binary contents of the file. The deep thing to me is that programs can not only encode instructions for the computer, they can also encode how to do the decoding. Obviously you then need some common convention (like shebang) to say how you can interpret the part that tells how to interpret the content.

There would be a step anyway between the user selecting even a regular binary executable (via pressing enter after writing its name on the shell, by double-clicking on it in a desktop file manager, by running a shell script which on some line invokes it, etc) and it starting to execute (the shell or GUI would have to interpret the action and tell the OS to execute the binary).

So adding an intermediary to do a choice of executor and/or handover in between (whereas at the shell/file-manager level, or at the OS call level), but still before execution, is quite easy.