Aside from the fact that, as mentioned in other answers, if the computer isn't running then it's not possible for it to do stuff, the big clue here should have been the Red Hat documentation explicitly pointing out that there's a choice of softwares for performing these tasks, and they behave differently. What's unmovable varies from software to software. Different disc defragmenters have different ideas about what is and isn't movable, and will refuse to move different things.
For example: Back in the years of MS-DOS/PC-DOS/DR-DOS and DOS+Windows most disc defragmentation utilities refused to move any file tagged with the system or hidden attributes. This was on the grounds that the BIOS files, ibmbio.com or io.sys, were specially placed on the disc, because of limitations in the FAT VBR bootstrap loader code used by DOS. The BDOS files, ibmdos.com or msdos.sys were loaded by a more capable loader program in the BIOS and didn't have all of the same placement restrictions. But the disc defragmenters didn't know what files were what, given the variation in names, let alone cope with the subtle variations amongst multiple DOS versions and additional things like the Windows 3.x paging file, SuperStor compressed volumes, and so forth. So they fell back on the simple to implement assumption that any files marked with those attributes, as all of the aforementioned usually were by default, were thus designated by the system administrator as unmovable.
Windows NT has, since version 4.0 if memory serves, defined a standard defragmentation API that FSDs are supposed to implement and that disc defragmentation programs can employ. So on Windows NT nowadays what's considered unmovable is generally the province of the filesystem driver (FSD) rather than the disc defragmentation utility. So what's considered unmovable in — say — an NTFS volume depends largely from what version of the NTFS FSD one is using. One of the features touted at the release of Windows NT 5.1 was improvements to the NTFS FSD that allowed defragmenting directories, the MFT, the volume bitmap and other metadata MFT entries, encrypted files, and files where the volume's allocation unit size was larger than 4KiB.
All of this variation, from utility software to utility software and from FSD version to FSD version, which is outwith the scope of what it's trying to describe, is what Red Hat covers in the four words "one reason or another".
