I very strongly doubt this is part of the browsers same origin model. Basically, this is only secure under the assumption that the third party script can't trick the first party script into invoking it by modifying its state since the third party script and the first party script both share the same global namespace.
Lets see how this is broken when jquery is running as a first party script.
1. third party script calls $(document).on("..", function() {})
2. event executes which causes jquery to invoke a function in the third party script
3. third party script can now make a request to the 1st party origin bypassing the 'sandbox'
ok.. so maybe the browser tries to 'secure' against this attack by marking event listeners as either having a 'good' stack or a 'bad' stack. in this case when the third party script does $(document).on() it would be identified as 'bad' stack and couldn't then make the http request because the browser would see <bad stack> at the start of the event chain.
but this can still be worked around:
1. third party script calls $(document).on("event", ".selector", function() {}) after 1st party script had already set a listener on document (not an abnormal thing)
2. event happens and now it is run with 'good' stack because jquery uses a shared event handler and the event handler was originally registered with 'good' stack by the first party script. (the bad script doesn't even have to use the 'live' style. i suspect jquery shares event handlers for the same element so they would just need to try to add an event handler to an element that already has a jquery event handler)
there can be no security between scripts that share the same global state.