The main thing which was absent in the 68000 but added in the 68010 was the ability to have an instruction execute until it attempts to access a protected region of memory, trigger a page fault, have a page-fault handler swap in the memory as required, and then have execution resume in the middle of the original instruction. Such scenarios would not have been generally supportable in a single-CPU 68000-based system(*) because some of the 68000's instructions may perform multiple memory operations in ways that are not interruptable. Suppose, for example. that A0 is $20002, and code performs ADD.L R0,(--@A0) when the page at $1FFFE is fully read/writable, but the page at address $20000 is a copy-and-write page which is marked read-only. If an attempt is made to perform the instruction in such circumstances on the 68000, it would perform 16-bit reads from addresses $1FFFE and $20000, then write $1FFFE, and then trigger a page fault while trying to write $20000.
Once that occurred, it would be necessary for the operating system to somehow copy the data from the page to a new fresh page, mark the new page as read-write, and map it to address $20000 where the old page was, and somehow have the final write from the earlier instruction be performed onto the new page. Note that re-executing the instruction would not work because it has already modified the high-order (lower-address) word of the value, and repeating the instruction would erroneously modify the high-order word again.
There are two approaches that can be used to handle this in a single-CPU system:
Have a processor signal to the MMU what areas of memory are going to be written before the committing to accessing them, so that if a page fault is going to happen it will occur before memory has been modified. Doing this would also require that the processor be capable of unwinding modifications to any affected address registers (like the pre-decremented A0 in the above example), but this approach is used by many systems today.
Have the processor's bus fault handler store on the stack information about current instruction progress, in such a fashion that when the trap handler resumes, the processor can finish off whatever parts of the instruction hadn't yet been executed successfully. I think this is what the 68010 did.
Making #2 work in all situations for all of the instructions in the 68000's arsenal involves adding a lot of complexity, which pushed up the amount of circuitry in--and thus cost of--the 68010. If one needs a single-CPU system that can efficiently handle virtual memory a complex instruction set and without an on-chip data cache, such complexity may be unavoidable(**), since having to interrogate external memory about whether it can be written prior to accessing it would slow things down.
(*) Some machines by DEC (I think their Alto workstations) used two 68000 processors, only one of which could be running at a time. One of the processors would run "ordinary" code, but if a bus fault happened it wouldn't be interrupted. Instead, it would be frozen while the other 68000 would start code execution, use some circuitry on the motherboard to find out what kind of access the first CPU was doing, swap memory pages as required, and then allow the first CPU to resume operation. Having the first CPU exist during page fault handling solely for the purpose of maintaining its state, and having the second CPU exist solely for purposes where the first CPU had to be kept frozen, may seem wasteful, but it was the most practical way of doing what needed to be done.
(**) If the above example were being done on a system with a 32-bit bus and a cache, the system would probably read words at $1FFFC and $20000 before writing anything, and the MMU could have informed the CPU during each read whether the associated memory is writable. Thus, the CPU would know--before starting the write operation--that it would fail. Alternatively, some architectures deliberately avoid instructions that combine multiple operations in ways that would not allow for re-execution. On something like an ARM, if one uses an STRMIA instruction to store 13 multiple words of data and a fault occurs while writing the tenth word, registers will be rewound to the state prior to instruction execution. Re-executing the instruction would cause the first nine words to get written again, but that would generally be harmless since--unlike the example with the ADD instruction--the STRMIA instruction would be unaffected by the earlier contents of the memory in question.