JSONP is not actually JSON with padding, it's Javascript code that's executed. JSON is not a real subset of Javascript and the way it is not is important to us: via UTFGrid, we are all UTF-8 masters.
JSONP is not safe: it's Javascript that's executed. It's trivial to XSS with JSONP, because JSONP is XSS. Just have a call like mapbox.load('foo.tilejson', …) and if foo.tilejson gets replaced with destroyYoursite(), it gets run. Compare to JSON.parse, which is, on purpose, not eval.
JSONP is questionable in terms of performance. To be fast, you want to have the same callback all the time so that you can cache the response. But this leads to a page like
<script>grid('a');</script>
<script>grid('c');</script>
<script>grid('b');</script>In which the grid function is called by several relatively-anonymous script tags in quick succession. The events browsers give us for script loading suck: the load event isn't the 'evaled and executed' event, it's just the load event. That sucks.
The less performant way to do things is with dynamic callbacks, like foo.php?callback=foobar123213. So every response needs a new request and your cache sucks.
The future is CORS but it isn't the present: it isn't supported on IE<10. So, we're jfdi'ing it: which means XDomainRequest. Which sucks.
IE sucks, but you choose your kind of suck: the restrictions of XDomainRequest - only the GET HTTP verb, no headers, etc - shouldn't matter to us.
One thing: unlike JSONP, where HTTPS throws a warning but can work, XDomainRequest totally falls flat on HTTP->HTTPS or vice-versa.
