That is, are any of the operational levels designed in a way which writes over or otherwise destroys existing data on the disk? I looked around but couldn't find an answer to this question, and can't deduce it from the jargon used by Spinrite documentation.
The short answer is no. In fact, it will make previously unreadable blocks of data readable again.
Now for a synopsis of the long answer.. What Spinrite does is to test the operation of the disk at the hardware level. It does so by verifying the disk's ability to reliably read and write data. Because it does so outside of your operating system, using instructions directly at the hardware, it goes far beyond what Windows' built-in CheckDisk does. It reads and writes back to the whole surface of the disk. It reads each block, inverts the binary data and writes it back to verify writability, then re-inverts the data and writes it to disk, verifying again that the data is readable. This has the effect of not only verifying the ability of the disk to function properly, but also to refresh the data stored on the disk.
It's a fantastic program. I use it on all of my systems periodically, and on all customer machines when they first come into my shop. This has corrected many problems for me, including non-booting systems and periodic BSOD symptoms. If you're considering buying it, go ahead. Steve is working on updates to the program that will vastly improve the speed with which Spinrite works, and the updated program will be available for free to all owners of the current version (Spinrite 6.0).
To all intents and purposes I would say it does not destroy data and I do use the program and I find it very useful, if somewhat awkward to use with modern hardware.
If an OS tries to read a file containing a corrupted sector on a disk the disk usually tries briefly, then reports to the OS that the file is corrupted (the checksum tells the disk the sector was read incorrectly so it reports a read error). Most likely you won't be able to open the file at all.
If you run SpinRite on the disk (usually using Level 2 for data recovery), then it will force the disk to make very many more attempts to read the corrupt sector and it may well recover it and then rewrite it safely.
If you are running SpinRite on hardware that can fully access the drive (using the ancient commands that SpinRite 6.0 is still using) then it can read the individual bits of the corrupt sector and do a statistical analysis "dynastat" to try and correctly read the data (using the checksum to confirm that it got it correctly). If it fails to get it correctly, it may nevertheless have read the majority of it correctly, but because some bits are incorrect, the checksum does not match. What SpinRite does next could rile some people... it rewrites the sector with it's best guess of what it should read and it sets the checksum so the disk now thinks the sector is OK. So now when the OS tries to read the file containing that sector it will think there is nothing wrong with it.... however, some bits inside that file will be corrupt. Now that has good and bad effects. The corrupt bit(s) may be completely inconsequential. They may be in an unused sector. They may be in the slack space after the end of a file's contents. Or maybe the file is a text file and a few characters are now garbled (but at least the file is now readable). If it is a binary executable it may crash when run. If it is part of a FAT directory, then a filename may have some garbled character, or the wrong size... or wrong location... but most likely a bunch of previously 'lost' files will have re-appeared. So although it may sound bad to have a file with some corrupt data in it... in almost all circumstances you are better (or at least no worse off) than you were before running SpinRite.
Unfortunately, because SpinRite ignores the actual file system on the disk, you don't get any report as to which files are potentially corrupted. (on the plus side again - the fact that SpinRite doesn't consider the file system is an advantage in that it means it works equally well on any disk irrespective of what operating system or file system it contained... from mass memory to TIVO disks)
One other worry you may have is that for a dying disk it will tip the disk into failure. Perhaps spreading debris in the drive or fatally wearing out a read head. That has not been my experience. I can't say it can't happen, but in the cases of failing disks that I have encountered it has not seemed to make the problems worse.
one other very fine point ("fine" as in "picky" and "fine" as in "applicable") is that most File System-dependent drive and data programs do not do this: read and recover most (if not all) bad bits within a sector. This has made drives functional.
Once a drive comes back to life via SpinRite, BACK IT UP CONSTANTLY, (like maybe I should have done)?
And BTW: HEAT is a factor; I have never had several 320GB Western Digital 7200RPM drives (about 10) fail, still in use for over 10 years, because I spent the money and did the metal-craft where necessary, to mount those dedicated HDD fan assemblies directly to the bottom of the drive. I even wired some two-fan assemblies with the fans in series, run slowly and quietly, but still absolutely prevent overheating because they keep the air moving directly on the HDD, and their metal structures wick heat away too.
I do the same to SSD's (2.5 in) and will just KLUGE a way when I use mSATA and NVMe, to KEEP THEM COOL. Because they DO get hot in use, and that is bad, and that is why heatsinks are now marketed for SSD's as well as RAM.