I think this attempts to workaround limitations or inconsistencies in the API by introducing another API function on the GPUDevice. Instead we should address the limitations or inconsistencies without adding new API.

No, my claim is that both destroy() and simulateLoss() are useful for different things. destroy() to clean up resources easily during shutdown, and simulateLoss() for testing application behavior on device loss.

Specifically for the getMappedRange case on a lost device, should we just align the behavior to mapAsync when it is known the device is lost on the content timeline?

This would go against #1629. Of course, mapAsync already does, but I think that's more OK because it's async. That said, we did leave open the possibility of making mapAsync work on lost devices, too: #1629 (comment)
I think we mainly avoided it to simplify implementations, though I don't think the implementation is actually complicated.