/dev/shm is used by the POSIX shared memory implementation (i.e. shm_open) and can also be used as a general temporary directory (like /tmp) that's memory-backed. Legitimate applications use it and legitimate applications will break if you follow this advice.
There's nothing inherently unsafe with /dev/shm - it's very similar to /tmp. It's possible some applications use POSIX shared memory unsafely, but that's a problem with those applications. Doing something drastic like making /dev/shm read-only, if it even serves a legitimate security purpose, should only be done as a last resort.
Read-only would be bad! You want no-execute on /tmp/, /var/tmp, /dev/shm and they should be their own partitions on a secure system.
The reasoning is that if someone does break into your system via apache/php or something else, they will almost always want to get a binary to elevate their access level (i.e. root the machine). They download a binary to a temporary location and execute the code (This can happen in apache/php directories too but most of the time these are locked down). Setting these to no-execute does not allow the attacker to execute code on your system. This is just a minor slowdown but does greatly help to prevent automated attacks.
The goal is to slow people down to improve your chances of being alerted. I think this is fiarly standard and is listed as a best practice via the NSA RHEL hardening guide [1].
"Setting these to no-execute does not allow the attacker to execute code on your system". It depends, with /lib/ld-linux.so.2 /tmp/script or bash /tmp/script.sh it may be possible to execute code on a noexec /tmp .
As you said, setting noexec still helps preventing automated attacks.
It really doesn't matter, its permissions are 0664 and the uid/guid are 0/0 (root.root).
It may protect you in case of a mistake, your editor should warn you that the file is read-only.
I don't like the post, it's too complicated for small benefits (if any). Besides there's no "generic secure setup", I think it depends on what you want to do with that server (ie. making /dev/shm read only may have impact on some software).
I tend to agree with you about the "generic secure setup". The problem with making read only some parts of the file system, as other persons said too, is when a legit application will want to access those locations, a better solution is to remove execute rights on the desired locations.
Why isn't this the default? (in other words: what does benefit from ro not being the default besides people trying to hack into the box?)