Historically, the Abort/Retry/Ignore question in MS-DOS was a result of an I/O subsystem which had no way of reporting problems from the disk sector level through the file-system level to the underlying application. If an application asked to read some data from a file, and block 1571 of the disk was unreadable, there was no defined mechanism by which DOS could tell the application "Sorry--it turns out that part of the file is unreadable". The choices were:
Abort -- Kill the application altogether
Retry -- Repeat the requested operation and hope it works. If a disk had been removed, reinserting the last disk that had been used might work, but inserting a different disk may be disastrous.
Ignore -- Give the application some random data and hope for the best.
Note that Abort did not mean "just cancel the requested operation"--it meant "kill the application". This could sometimes be very unpleasant. For example, if one accidentally tried to save a file to a write-protected disk, removing that disk, removing the write-protect tab, and then reinserting and hitting "retry" might work, or if there wasn't room for the file it the application would be informed of that; that wouldn't be a good option if the disk had been write-protected for a reason, however. Hitting "ignore" enough times would cause the application to think the file had been written to the disk even though it actually hadn't, though I recall one would have to hit the key for every sector the application tried to write. Hitting "abort" would kill the application entirely, which--if the reason one wanted to save is that one had just done a lot of work--might make one want to throw the computer through the window.
Note also that during the early days of DOS, changing disks when presented with an Abort/Retry/Ignore prompt for a write-protected disk was often recipe for data corruption, since the write-protect tab wouldn't be detected until the system had decided which block it was going to write, and the effect of swapping disks would be to cause that block to be blindly written on the new disk.
In more modern contexts, I would suggest that "abort" and "cancel" should not be considered synonymous; the difference in meaning may be illustrated if one imagines three software-update processes:
At any time prior to the completion of the update process, one may interrupt it, and doing so will leave the system in a state similar to that before the process began.
At any time prior to the completion of the update process, one may interrupt it, but doing so will leave the software in a state that will be useless unless or until the upgrade process is restarted from scratch.
At any time prior to the completion of the process, one may interrupt it, leaving the software in a state which will be useless unless or until the upgrade process is completed, but the process may be resumed from the point of interruption.
The first action above I would call "cancel"; the second, "abort". The third scenario I would call "pause" or "suspend" [probably have a button marked "pause", which would then offer descriptions of available actions including "suspend"]. Generally, software should endeavor to avoid the second scenario, since users will typically want the first or third. Since software should avoid forcing users to pick the second scenario, it should thus generally not have an "abort" action. In cases where software cannot gracefully interrupt a process but a user may be willing to accept the consequences of a rude interruption, however, the term "abort" may be appropriate.