The second way uses a lazy event handler. This means that if you manipulate the DOM after you have initialized these events, only the second method will work.
This is because the second event handler attaches to the document and not the #someID element directly.
Whenever the user clicks in the document, jQuery will determine if the clicked element matches the #someID selector, and only then will it fire the configured event.
This allows you to add the #someID element at a later point, even after the events have been configured.
The official name for this is event delegation, and you can find more info and examples here.
Edit: note that there is a performance penalty when using the second method. This is because jQuery has to search through your entire document for matching elements on every click. While #someID can probably be matched in a very fast, performant manner, you should at least be aware of this mechanism.
If you still want the advantage of having lazy events but want to minimize the performance overhead, I would advise you to narrow the scope in which jQuery has to search. For example, if the #someID element will always appear in the #someContainer element, you should configure your event like this:
$("#someContainer").on("click", "#someID", SomeFunction);
Another thing to note is that this method can also have performance gains. I am speaking from personal experience and have no benchmarks to prove this, but I noticed a smoother experience when using this method on a large collection of objects, for example a ul tag with lots of li tags, where each li tag needed an event listener. In this scenario, it was better to attach one event listener to the ul tag rather than attach n events to n li tags.