Assertions are popular in languages without exception handling, for making checks to ensure the program is operating correctly, so as to make problems easier to diagnose.
However there can be some ambiguity as to what the most appropriate cause of action is if an assertion fires. If the program exits immediately, there may have been a wasted opportunity to handle the failure more gracefully (e.g. reporting the failure to the user and attempting to recover data). If the program does not exit immediately, it could be in an unknown state because of the error, which is also undesirable.
As a result it is considered better practice to throw exceptions in Java when a given condition fails, which allows a best-of-both-worlds solution to these problems. For errors that can occur during normal operation of the program, checked exceptions most appropriate. Calling code is obliged to handle these errors. For errors caused by failure internal program logic, throwing a RuntimeException would allow the program to handle the failure appropriately further up the call stack.
Asserts do have one benefit which is they can be employed in development, but can be 'compiled out' for a consumer or release build, where speed of execution is more of a priority than early detection and handling of errors. However apps that require that characteristic are not commonly built in Java (more likely C++), which is again why assert is rare in Java.
(Also, I believe that assets at runtime are not always enabled by default by some IDEs anyway, so it is easy to have an assertion fail and not know about it.)