The biggest and most persistent issue seems to be that multiple copies of fairly heavy Javascript and CSS resources get loaded and parsed, one per per widget, on top of a relatively heavy document per button in the iframe itself, resulting in a rather quick inflation of the overall delivered page. PageSpeed says that for a simple test page with 10 "Like" buttons, a whopping 1.2MB of JS is parsed and run [1]. This doesn't include the additional overhead for the CSS; the total delivered size for 10 widgets is in the hundred of kilobytes. Anecdotally, I was able to reduce the heap size (as reported by Chrome) of some of our slower (to render) pages by a full 50% just by removing Facebook widgets, resulting in notably snappier page loads. Putting a bunch of Facebook widgets on a page just obliterated its load speed. We had issues with some pages actually crashing or hanging user browsers, and we consistently came back to the Facebook widgets as the biggest offender. Each iframe has to be parsed out into a document, its inline script run, its external scripts loaded, parsed, and run, and attached styles loaded and applied. Multiply by 20 buttons on a page and it got really slow really quickly.
What really impressed me about the Google implementation is that it collects the information about all the buttons on the page, and then fires off a single call to retrieve all information necessary to build them out (the /rpc call that seems to happen after just about everything else). That happens later in the page lifecycle, so the +1 button seems to take a bit longer to come up, but because it's all firing off at once it seems to result in a smoother overall page load experience. While I don't have a good unit test in front of me, I've often felt like pages stall out on Facebook widgets, and as far as I can tell, that's not really a concern with +1. The actual iframe loads are quite quick, the iframes are small, and are obviously built to render ASAP. The heavy lifting occurs much later. The Facebook widgets have seemed to be to be built with the assumption that there will ever only be one per page (heavy iframe document, multiple external scripts that will have to load in serial), resulting in pretty terrible bloat when you had multiples.
That said, in all fairness, in some quick tests tonight, the Facebook widgets seem to be far better-behaved than they were a few months ago, so it may be that my complaint is no longer relevant.
[1] http://pagespeed.googlelabs.com/#url=http_3A_2F_2Fdl.dropbox...
Edit: Not really a complaint, but an observation - the like.php widget has an XHTML 1.0 doctype, which requires closing tags for non-empty elements. An HTML4 or HTML5 doctype would make that valid, though.