I don't see any flaws in the technique, and its a very cool technique. But one problem I see is that you have to have the responding server package the data correctly for transport via this method.
Meanwhile, doing JSONP simply requires the data on the 3rd party server be delivered in a JSON format, while this requires the special 2kb packaging.
Its definitely a more secure way of obtaining remote data from untrusted 3rd parties, but the trade-off is that the 3rd party has to be setup to correctly deliver the data.
He does say that "Unlike JSONP, untrusted third-party JavaScript cannot execute in the context of the calling page." I'm not sure why, and I would assume that's as long as you never call eval(), but it would be good to know why he thinks this is a more secure idea.
Also didn't see a list of browsers it supports. That would be helpful too. If it's widely supported, this could be a good way to get data feeds from 3rd party sites and not have to do any server-side processing on your end.
Looking at his source, he does an eval() in the first line of his response handler for the flickr example. I imagine you could do a JSON.parse() instead of eval() -- preferably! -- but if he says it's secure, what about that line?
They key here though is that evaluating untrusted code from a 3rd party site is not a requirement of the transport. That eval is in the client code and it could just as easily be a safer alternative (either checking that it's sanitary with a regex or using a library's JSON decode function)
With JSONP you necessarily have to execute untrusted code, since JSONP works by loading JavaScript in a <script> tag.
Meanwhile, doing JSONP simply requires the data on the 3rd party server be delivered in a JSON format, while this requires the special 2kb packaging.
Its definitely a more secure way of obtaining remote data from untrusted 3rd parties, but the trade-off is that the 3rd party has to be setup to correctly deliver the data.