reason to add execute permissions to a shell script

Yes, you can use bash /path/to/script, but scripts can have different interpreters. Its possible your script was written to work with ksh, zsh, or maybe even awk or expect. Thus you have to know what interpreter to use to call the script with. By instead making a script with a shebang line (that #!/bin/bash at the top) executable, the user no longer needs to know what interpreter to use. It also allows you to put the script in $PATH and call it like a normal program.

The security feature lies in the combination with the suid/sgid bit, but read on.

Exec bit alone is now mainly a convenience - it shows which files are meant to be directly executed.

• when typing commands, files w/o exec are not run in the current dir, if you have "." in your PATH
• TAB autocompletion can suggest only files w/ exec bit if it sees you are typing a command name
• users can better see what files are to be executed
• it tells kernel that the file whose name user typed is a command and the kernel should bother to open it and find out what it's loader/executor is.

But it does not prevent a dedicated user to run the file, as others already shown.

The catch is, that when you can circumvent the (lack of) the exec bit when running the file with an explicit loader, you also do not use its suid/sgid bit, so you do not get elevated privileges.

Let's have in /bin

 -rwsr--r-- root root some_privileged_command

You can execute the command as an unprivileged user with

 $ /lib/ld-linux.so.2 /bin/some_privileged_command

but it will not be executed with root permissions, unlike

 -rwsr-xr-x root root other_privileged_command

that will, if you exec it directly as

 $ /bin/other_privileged_command

That said, it's moot for shebang commands anyways, because they won't be executed with root perms even with suid set - for that, the shell executable itself would need that bit (and it would be really, really bad to do it).