Unix execute permission can be easily bypassed. Is it superfluous, or what's the intention behind it?

You can set the execute bit, but not the read bit, on an executable file. That way, noone will be able to copy the file, but people can execute it anyway.

This is quite pointless today, because a) it works for compiled programs only, not with scripts (on most systems); b) these days, with 90% of all unixes being linux, people can copy executables from just about anywhere, and c) the disk space a copied executable takes doesn't really matter.

Still, there were uses for that in the old days.

The Unix system i used at school, 30 years ago, was very limited in RAM and Disk space. Especially, the /usr/tmp file system was very small, which led to problems when someone tried to compile a large program. Of course, students weren't supposed to write "large programs" anyway; large programs were typically source codes copied from "somewhere". Many of us copied /usr/bin/cc to /home/<myname>/cc, and used dd to patch the binary to use /tmp instead of /usr/tmp, which was bigger. Of course, this just made the problem worse - the disk space occupied by these copies did matter those days, and now /tmp filled up regularily, preventing other users from even editing their files. After they found out what happened, the sysadmins did a chmod go-r /bin/* /usr/bin/* which "fixed" the problem, and deleted all our copies of the C compiler.

Another use is to tell the shell which files are intended to be executed and which aren't. You don't want a a random text file executed because you typed its name; the x bit provides a way to prevent this. (These days, the shell could just look at the start of the file, and only execute it if it starts with #!, but this was introduced much later). bash's completion feature, as well, will suggest files with executable bits only when you're typing a command.

There is a readymade way to execute an arbitrary file: pass it as an argument to the dynamic linker (which is the appropriate interpreter for a dynamically loaded executable). E.g. under Linux,

cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/ld-linux.so.2 /tmp/ls

However, this comes with the same restriction as reading the file and jumping to code: the setuid bits are not evaluated.

In the old days, we'd often have binaries like /bin/su:

-rwsr-xr-- root wheel  ...  /bin/su

Only members of the wheel group, which the sysadmins kept trimmed to people knowing the root password would even be able to execute the su command, so even if a buffer overflow existed in that binary, allowing callers to bypass security, the exploit would be usable only by people who know the password anyway.

If you for some reason want to keep the binary code secret, you can make the program executable without being readable. This is not useful if those users have physical access to the machine. It is also not useful if the source or binary code is widely available. So this is a fairly limited use case.

If the program has a setuid or setgid bit, execute access does something more, than what can be achieved by reading the binary. One approach is to create a setuid executable which is only executable to a specific group. If it was world readable, people outside that group still couldn't copy it and make use of the setgid bit on the original executable. (Though in most cases I would rather use setgid than setuid, and then use the group on the directory to control who can access the executable.)

Usually the executable bit is simply used to indicate which files are programs in the first place. That way completion can work better, and you don't execute unwanted executables by accident.

If you want to prevent users from copying an executable and running it, you can mount home directories with noexec. In order for this to make sense, you have to use noexec to every file system, where the user could write anything.