/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.
/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.