Historical Addressing Modes/Conditions that Complicate Page Fault Handling
The Motorola series of CPUs stored different amounts of processor-specific state on the supervisor stack when handling most faults (including page faults).  This (intended to be opaque) binary blob was, in essence, a dump of the CPU's internal state at the time the fault was discovered, allowing the CPU to pick up where it left off should you decide to restart the operation.  However, I'm not aware of any other processor that (re)stored its internal state in this way.

Disclaimer: speculation based on vague memories follow.  While storing microarchitecture state on the supervisor stack was effective, I recall that it also impacted forward/upward compatibility of operating systems (this was totally hidden from user-mode).  The rough inability to predict how changes in the microarchitecture would impact the fault handling logic made supporting kernels more difficult than, say, for x86 where backward compatibility was a philosophy set in stone for not just ring-3 code, but for all rings.

Another concern is latency; Motorola's approach to solving this problem involved automatically storing up to (IIRC) 16 long words to or from the stack.  You don't get a say over this, which makes Motorola's processors some of the slowest-to-respond to various kinds of faults.  Since different operating conditions can affect which stack frame gets pushed, latency further wasn't predictable without very detailed knowledge of internal CPU state at the time the fault occurred.  One good reason why processors elect to restart from scratch instead of storing current state is that it actually improves performance and makes things more predictable.