Okay, I can see what you were thinking. But, as I said, CHKDSK doesn't normally do a surface analysis; it just checks structure.
Over the years, I've discovered CP/M disks with out-of-range block numbers, and duplicate block numbers in the same file as well as two files sharing the same block number. Oddly, those aren't nearly as disastrous as FAT filesystem structural errors. Usually, you lose only one block's worth of data in a file with such errors. Things such as missing extents are okay ("sparse" files are legal) as well as strange characters in file names. Unerase is pretty simple, as long as the original data hasn't been overwritten.
In short, CP/M structural errors are far less common that FAT filesystem ones. You gain a certain amount of efficiency and versatility by using a linked structure, but that same added level of complexity sets the stage for more serious problems when things don't go right.
Recall, also that CP/M was spawned in the early days of floppy systems; hard disks were beyond the budget of most people and organizations. SC-DOS and MS-DOS came alone when hard disks were well established.
If you look at some competing operating systems in the CP/M era, allocation was contiguous, with each file being pre-allocated. This gives you efficiency in access (no fragmentation) and reliability (no advanced structures other than a directory showing size and starting sector), but imposes a penalty with regards to being able to extend files. Defragmentation/repacking the disk was usually done with separate utility. Depending on the application, this could work quite well.
CP/M's file structure is sort of a happy medium, geared toward the floppy user.