Non-nullable is a promise not a guarantee. It does absolutely nothing in terms of useful warnings or compiler errors within Objective-C, it only explains how Swift should consume the Objective-C API.
It's still entirely possible to get a nil from Objective-C while the API is declared as nonnullable, this even happened to me with Apple's own API's if abused to a certain limit.
Yes but if Java 10 (for example) introduced this annotation then the JVM10 could transform a null returned from a non-nullable annotated function to an exception. Compile time static checks could also be added to guarantee that such a method does not return null. But you could still use such a function from a previous java version albeit you would sacrifice the checks.
It is a way to introduce the benefits (as long as the library is developed properly) of non-nullable types without sacrificing retro compatibility.
Edit: I remember a bug in earlier version of Swift Cocoa binding where getting calendar events without titles would hang without possibility of recourse because of this problems.
It's still entirely possible to get a nil from Objective-C while the API is declared as nonnullable, this even happened to me with Apple's own API's if abused to a certain limit.