The reason that SDelete does not securely delete file names when cleaning disk free space is that deleting them would require direct manipulation of directory structures. Directory structures can have free space containing deleted file names, but the free directory space is not available for allocation to other files. Hence, SDelete has no way of allocating this free space so that it can securely overwrite it.
From what I can make of M/S's description of Sdelete, it is saying that it doesn't (and can't) use its chosen secure overwrite method, to wit the DOD standard, to overwrite file names in the MFT, so instead it renames the files 26 times, which might be considered secure if not overkill.
If Sdelete did what it said then one would end up with a jam-packed useless disk. It doesn't seem to say that at the end of the allocation and overwrites/renames it deletes all the files it has created, but perhaps I'm nit-picking.
I have no idea how Piriform are going to manage overwriting 'spare' filenames in the MFT, and they probably won't tell us. I hope they won't use Sdelete's method. Maybe it will be to scan the MFT, count up the number of slots containing deleted file names, allocate the same number of new small files with some max length file name, then delete the lot. Huh, anyone could do that!
It comes in both installed and portable versions. Open it, go to Tools -> Tracks Cleaner (at bottom) -> Evidence Remover, select the desired drive and run it. Once done, run Recuva and you'll see that everything's gone. Just beautiful and safe.