I think the major difference is in the name: webbrowser.open should always open a webbrowser. Java’s ...Desktop.browse still evokes a browser, but the “desktop” in the name at least hints that it might not be a web browser that gets opened.
However, I do agree that we should have a standard API for “do the system default for this URI”, but I’m not sure where it should live. webbrowser seems out of place regardless of the function name because the whole point is that we don’t necessarily want to open a web browser. The functionality most reminds me of os.startfile, which has always been a Windows-specific way to launch a file the way the OS wants, but os doesn’t strike me as a great place either (though it may still my front-runner of the options I’ve come up with) and I’m not sure what we would call the function – os.starturi? 
I wonder about something like urllib.launch(uri), but that feels different from anything else in urllib, even though that package is specifically about dealing with URIs.
For some further reading, see also Support for `file://` urls in webbrowser.open and webbrowser.open with file: URLs may launch editor instead of browser (gh-128540) which have also recently changed webbrowser on macOS. Also tangentially related is this old proposal to Add shutil.open (gh-47427) as a cross-platform os.startfile.