Except in this case (original article) it was an executable inside a zip file.
In the normal case, unzipping a file on linux will result in the executable bit being restored if it was included on the original file.
This is normally what you want - imagine an app that was distributed (over https) as a zip file where you then had to go and manually add the executable bit to each relevant file.
But a zip file that was opened as an email attachment is largely indistinguishable from one that was opened from an HTTPS download (it need not be that way, but it is), so the OS has no reliable way to allow you to run executables you download in a zip, but not ones you received as an email in a zip file.
There are certainly ways around it, but the executable bit isn't really the solution here.
While that is useful, in Windows-land the result would only be another message box to click-through, asking if you wanted to make the file executable, which no average user would understand, and therefore just click OK. If they even took the time to read it before clicking through.
Better to sandbox any executables received from external sources.
The absence of that executable flag does nothing to protect you from using an existing executable and some data such as an interpreter and source code.
On Linux there is a specific flag that has to be set and is not set per default to make a file executable.
So if you run something, you know that you are running it as a program and not opening it as data.
Windows on the other hand marks everything as executable which begins with MZ and whichs filename ends in .exe or .com