If the site were still up, you could verify it in Google Webmaster Tools, put up a robots.txt for that subdomain that excludes crawlers from crawling anything, then go into GWT and request the entire subdomain be removed.

Here's how I dealt with a similar situation in the past.

Robots.txt on each of the dev subdomains and on the live domain. Dev subdomains robots.txt excluded the entire subdomain, and subdomains were verified in GWT and removed as needed.

Made live subdomain robots.txt read-only so it didn't get overwritten. Should have made dev subdomains robots.txt read-only as well, since they sometimes got refreshed with the live content (there was a UGC database that would occasionally get copied to a dev subdomain, and we'd have robots.txt get copied over too and dev subdomain indexed).

Set up a code monitor that checks the contents of all of the robots.txt daily and sends me an email if anything is changed.

Not perfect, but I was at least able to catch changes soon after they happened, and prevented a few changes.

Whatever happened here? Were you able to make your case to them at all, or are you stuck with the question?

Did the author's reply in the comment of the blog post answer your question, or do you still have this question?

If you've noticed this anomaly in SEOmoz tools, email the SEOmoz help desk. If you've seen it in Majestic SEO, email their help desk -- SEOmoz and Majestic are two separate companies with two separate tools.

Yahoo's Smushit.it is a tool that can do some lossless compression on your images and may be of use. If you use Wordpress, there's also a smushit plugin that will compress your images on upload.

Page load speed does have an impact both for users and search engines. It's certainly something to consider.

Just make sure that when/if you copy over the staging site to the live domain that you don't copy over the robots.txt, htaccess, or whatever means you use to block that site from being indexed and thus have your shiny new site be blocked.