checkExit. Ability to prevent accidental invocations of System.exit is very important for any application that deals with other unknown libraries (as IDEs do). JDK-8199704 is filled for this, but there is no proposal for an API yet, so it is impossible to tell how the API will cover this use case. The current API allows, for example, to partially simulate the effect of System.exit, while it also allows to provide a user-understandable message when a real exit is rejected.

Watching file system access. In various places, both in production code and in tests, SecurityManager is used as a tool to receive notifications of file reading or writing. This is especially important in integration tests, to guarantee that code is never accessing disk, unless absolutely necessary (for performance reasons, among others). In principle, the WatchService could be used for these use cases. However, the WatchService is not guaranteed to work (e.g., due to OS restrictions), it cannot detect read-only access, and requires subscription to individual Paths. SecurityManager provides a more reliable way to monitor all filesystem access done by Java code.

Warning or prevention of use of obsolete and/or dangerous idioms. The SecurityManager is used to warn about the use of obsolete System properties (via checkPropertyAccess) and the use of`sun.misc.Unsafe unsupported APIs via checkMemberAccess.

Identifying User Application Windows. The showWindowWithoutWarningBanner permission is used to track which windows belong to which user’s custom application (so that they can be closed when call to System.exit is intercepted).

Misc. There are also restrictions on potentially dangerous code, which are probably less important and are covered by Reinier’s e-mail. There are also few (probably) obsoleted workarounds.