This is what the Servlet 3.0 specification has to say about dispatcher behavior:
The getRequestDispatcher method takes a String argument describing a
path within the scope of the ServletContext. This path must be
relative to the root of the ServletContext and begin with a ‘/’, or
be empty. The method uses the path to look up a servlet, using the
servlet path matching rules in Chapter 12, “Mapping Requests to
Servlets”, wraps it with a RequestDispatcher object, and returns the
resulting object. If no servlet can be resolved based on the given
path, a RequestDispatcher is provided that returns the content for
that path.
Nowhere does it mentioning returning null if a matching servlet cannot be found for the dispatch path. Instead it states that the 'content' found at the dispatch path will be found, which I translate as meaning an implementation can simply allow the container to absolutely resolve the path (which in your scenario yields a 404).
As far as the Javadoc though, it seems documented with the broadest use case possible, aka, if the container cannot create a dispatcher for any reason then it will return a null object (as opposed to throwing an exception). This may be due to a technical problem in the implementation, or may be actually valid (e.g JAX-RS implementations can access some level of the Servlet infrastructure, but cannot use the servlet context or dispatcher).
