Most of the time, they won't need it. When they do, they'll need to make the case to you explicitly. Some phone apps currently do this when they need a non-obvious permission.
I think that the point is that most users can't be expected to understand the risks present in allowing a high resolution timer. It's a very nuanced decision, unlike camera and storage and location.
Most web apps are unlikely to need high-precision timers. For games, however, Date.now() offers only millisecond resolution, which can make it occasionally inadequate.
I'm developing a website that will require somewhat high frequency timing to account for network latency but I think standard getTime is accurate enough with millisecond accuracy which I think will satisfy my requirements (I still need to test this though).
I can't think of something that needs microsecond level timing though.
I agree; I would like to see a move away from trying to cram everything into a browser app, and towards adding better connectivity and community features to native apps.
Which is why you 1) want to ask, 2) default to "no", and 3) explain that the request is both unusual and potentially harmful.
The option to blacklist an app from such requests should also be present.
If the app itself absolutely cannot perform some function w/o high-precision timing, that becomes its problem to communicate to the user.
I've made a practice of denying application permissions, and deleting apps that make such requests. I'm moving to deleting Android entirely, which has proved overall to be a poorly-performing and functioning virus and attack vector, at cognitive, social, economic, political, and other levels. Also, frequently, software.
