One big difference to consider is that on PC DOS, the game runs at a resolution of 320x200 and furthermore only uses the 16-color mode. The 16-color mode alone translates to a difference of 4 bits per pixel vs nowaday's 24 bits.
Anyway, framestepping is not even a feature in original DOS Lemmings. It has its special challenges apart from normal gameplay rendering, because it's not practical to keep an in-memory snapshot of all the game states since start of level, so the implementation inevitably ends up loading the closest snapshot and then fast-forward from it to the desired point (frame) in time after that snapshot. There is a tricky balance between how many snapshots to keep vs how quickly the game can seek to the given frame. It should be clarified that there is generally no performance issue in the case of merely stepping forward one single frame (like the game already does during normal play), it's the other cases of framestepping that are tricky.
As for BitBlt, it is a Windows API that has been around for a long time and fairly commonly utilized, so it's very likely that some hardware optimizations are available for it at least for certain cases. On the other hand, it was not originally designed for gaming purposes (at least not specifically so), and while I'm no expert in the history of graphics support in Windows, it is telling to me that DirectX was developed specifically to support gaming on Windows, which to me strongly implies that the design of APIs like BitBlt were probably not entirely up to the performance standards required by gaming even at that time (though it's also true that DirectX was also to help paved the way for hardware-accelerated 3D graphics, which they correctly foresaw to become critical in gaming).