This API seems clearly necessary to implement traditional FPS game controls.
On the other hand, I would not want my browser to have this kind of functionality. Arguably the main benefit of browsers is that they cannot do many things, and are thus relatively safe to use, not yet triggering the sort of fear normally associated with installing software on desktop platforms. Interfering with mouse movement would be one of the most dangerous and frustrating things Web pages could possibly do.
The specification draft acknowledges the problem of inability to interact with user agent and the rest of the OS in mouse lock mode. However, the suggested mitigations seem fairly weak. Users are not trained to hit Esc anytime their computer stops properly reacting to their actions - I certainly wouldn't think of doing that. A permanent reminder would be extremely annoying, and we cannot expect that it would be read anyway.
Fullscreen is one mode where browsers are expected to take more control over user interaction. Perhaps mouse lock could be appropriate in fullscreen. However, regular fullscreen applications do not use a mouse lock, so users are not trained to escape it - one can always move the mouse pointer to top of screen to get back their menu bar. The only related case I can think of is emulators, which release the mouse on certain modifier keys, such as Cmd or Ctrl+Option. So, I'm not sure how a safe UI would work even in this case.
I'm curious about the following provision in the spec:
Mouse events normally considered user gestures (e.g. mousedown, click) for security purposes (such as when allowing pop-up windows) should not be treated as user gestures when under mouse lock to prevent malicious cross origin click redirecting.
My understanding is that when browser is in control, the primary security concern is with making the user believe that they are interacting with a different site, and thus stealing confidential data the user types (especially passwords). Displaying a pop-up window sounds like a very minor issue when malicious code is already in main frame, can draw anything, and can control mouse movement. Is there a specific attack scenario where this limitation helps?