First off, you have to define "Regular Person"
Regular Non-Tech-Interested, Non-Tinkering Person: No.
Regular Tech-Interested, Tinkering Person: Maybe. Could possibly recover from basic platter damage(1 to a few thousand bad blocks), possibly from PCB failure of the overheating type. Not likely to recover from total pcb failure, motor failure, head failure, etc.
Regular IT Person: Yes. Can definitely recover from basic platter damage, possibly from PCB failure of the overheating type(if patient enough). Still not likely to recover from total pcb failure, motor failure, head failure, etc.
There may be better software out there, but all of my successful recoveries have used 3 or more the following 6 components:
1. Non-Windows OS for recovery platform. As far as I can tell, you need an OS with /dev. I've yet to figure out on Windows how to hit the block level device directly. Maybe the drive recovery apps do it, but I haven't had much luck. For marginal drives, it seems like Windows mounts the drive and starts trying to muscle it's way through reading it, which either locks up the UI or makes the drive worse by repeatedly trying to access the same damaged regions of the drive.
2. ddrescue (not dd_rescue). ddrescue is IMO a great example of "the culture of unix-like development(?)", which is to say it is simple, does one thing, but does that one thing really well in a refined manner. ddrescue basically does block level copying of a disk to a file, avoiding error areas on it's initial pass by randomly skipping ahead when read errors are encountered. Error areas are logged to a simple text file, and when the full disk has been read it uses the log file to go back and narrow down the error areas. Nearly every successful drive recovery I've handled used ddrescue. I've had disks that would not mount in Windows, and actually clicked rhythmically like they had head/pcb failure, that boiled down to a single bad block. The clicking was from the drive repeatedly trying to read the same location early in the mounting process.
3. testdisk/photorec. After using ddrescue, if the error areas affected the partition map, testdisk can often help recover the partition info. It's not particularly user friendly and not something I would risk telling a non-tech to use, but does what it does well. Photorec is an undelete program.
4. rsync. (sometimes used with #5). Basically a file sync utility. Could just as well be robocopy in Windows, although I think rsync may be a bit more intelligent in terms of doing an incremental update with repeated interruptions.
5. Cold. PCB/component failures that are heat related will obviously respond to the freezer trick. I had a drive that when warm, wouldn't mount at all. When chilled to freezer temps it would mount and be fully accessible for about 2 minutes. I was able to identify the overheating chip with a human digital instrument of the index sort. I took a small flat copper plate, about 1/16 thick and 1" long, applied thermal paste to it, wedged it on top of the chip while ensuring it wouldn't short anything else(chip was on drive side of PCB), then re-did the freezer test. With this make-shift heat sink I was able to get about 20 minutes of uptime on the drive, which was long enough to use rsync to do a full recovery.
6. Patience. None of the above methods is quick. A simple ddrescue recovery will take several hours at the least, and can take much longer if there are tons of error areas.
As for the non-recoverable scenarios, platter/head replacement supposedly requires a clean room, clean box. PCB replacement supposedly requires the ability to read custom firmware parameters from the dead drive and write said parameters to the donor PCB, or requires de-soldering/re-soldering of firmware/eeprom chips from the dead board to the new board. I haven't had success with PCB swaps since the days of 540MB hard drives.