This is cool but it should be used with caution. The time your thread spends sleeping may be reduced to nothing, but the time it spends working won't be. This could lead to all kinds of scenarios (timeouts, deadlocks, etc) that are only theoretically possible in realtime. It may or may not be useful to encounter these cases.
Edit: also worth mentioning that a good way of doing this kind of testing when you have full control of the code is by abstracting access to time operations to go through an interface and injecting mock/fake time objects.
But you don't always have access to the code, so I think this tool is very useful.
One problem of creating your own time abstraction class is not only that you need full control of the code base and introduce everyone new to project to always use this class. Some time-based operations can be quite hard to mock, such as wait for thread synchronization primitive or wait for IO with timeout. However those are most often usually used in the domain where you don't want to mock time because, as you say, there the wall-time and the processing-time is more often dependent on each other and you probably want to test everything exactly as it would run in production.
Edit: also worth mentioning that a good way of doing this kind of testing when you have full control of the code is by abstracting access to time operations to go through an interface and injecting mock/fake time objects.
But you don't always have access to the code, so I think this tool is very useful.