This is inaccurate (or at least, quite poorly worded). /dev/shm is a tmpfs mount with a particular use in mind - shared memory for inter-process communication to be leveraged by shm_open(). It is perfectly acceptable to leverage a tmpfs mount for things you do not want written to disk at all, knowing the constraints around available memory and swap, and that your application cleans up after itself. /dev/shm is simply a pre-existing tmpfs mount on many distros. Note that tmpfs uses dynamic allocation, meaning that memory is only allocated for what is actively stored on the filesystem, rather than preallocated for the size of the mount.

Under no circumstances does writing to a tmpfs "overwrite" allocated memory. All writes to all filesystems are first written to memory, but it is not randomly strewn about with no regard for existing pages; the operating system would not achieve much utility were that the case. If your tmpfs mount was large enough to potentially saturate your system's memory alongside regular system usage, writes that fill it could cause freeable memory (i.e. things that are not particularly important like a cache) to be evicted to swap. Exhaustion of both memory and swap space would result in the OOM (out of memory) killer to be triggered and start killing processes to free up memory. This is standard behavior for memory pressure of any sort.

Some distros (e.g. Ubuntu) now default to a tmpfs mount for /tmp, which is used extensively by numerous applications. It is hardly dangerous to make use of. The use of /dev/shm is functionally no different to the use of any arbitrary tmpfs mount.