The file is marked as executable, so the shell very reasonably tries to execute it by calling some well-chosen member of the exec() family (http://linux.die.net/man/3/exec).
The exec() function then needs to open and parse the file according to the formats it supports, which of course fails since the file is empty.
Do you simply mean that you expected the shell to validate this, and not try to execute empty files?
In Seventh Edition UNIX, /bin/true is an empty file; it is a shell script that succeeds at does nothing.
Some later commercial UNIXes are noted to have /bin/true contain nothing but comments containing a copyright notice for that nothing.
This was altered for 2008[2] to "A file that contains characters organized into zero or more lines."
The 2008 version is actually broken, since it contradicts itself -- a file cannot "contain characters" on zero lines.
[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...
[2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
I disagree. To me this doesn't mean that a file "contains at least one character", but that files are containers and their contained values are characters. Like most containers in computer science, the set of contained values can be empty, but it's still meaningful to say that it's a container that "contains characters".
I understand what happens here and why there is an error message in zsh, but I'm surprised by the fact that bash does not signal the error (exec returns -1, after all).
Bash includes logic to parse ELF[1], so I guess that after exec fails it tries to parse the file and has a special case for empty files.
[1]: http://utcc.utoronto.ca/~cks/space/blog/unix/BashSuperintelligentExec