Oh it is not nearly as good as I thought then. I actually tested it and zero byte exec still make exec() returns ENOEXEC on Linux. So a small binary is definitively more versatile...

Does any shell implement exec of a script as fork and reinit?

Probably Inferno, considering that it also runs proper binaries that way.

Does this mean that putting #!/bin/sh at the head of scripts actually slows them down (assuming you are running from an sh like shell)?

I suggest measuring; there's overhead to the failed exec() call certainly. It probably depends on a lot of other factors too (which, if any rc files are read in each mode, how fast your shell is to startup &c.).

I just tested this.

Files:

1.sh:

    true

2.sh:

    #!/bin/bash
    true

test1.sh:

    for i in `seq 10000`
    do
    ./1.sh
    done

test2.sh:

    for i in `seq 10000`
    do
    ./2.sh
    done

Times for test1.sh:

    11.484s
    11.590s
    11.405s

Times for test2.sh:

    14.273s
    14.391s
    13.847s

So including the #! adds about 23% to the overhead of calling a shell script. Tested on Mint 19.1, bash.

EDIT: for reference, sourcing the scripts instead takes an average of 0.0842s for test1 and 0897s for test2. (and all test2 trials were still slower than all test1 trials), which isn't particuarly suprising.

Inlining true takes about 0.029s

Why did you use bash and not sh for the interpreter?

To keep the comparison fair. My interactive shell is bash (which I assume is a more popular choice for interactive shell then sh), and the version without any shebang will use whatever the parent shell is. To make the comparison fair, I wanted the version with the shebang to be using the same shell.

Besides, /bin/sh would also require dereferencing a symlink (to /bin/dash), which also doesn't seem fair.