Jeffrey @Zeldman is the Godfather of Web Standards. I learned to read [HTML] with Designing With Web Standards, a graciously simple and seminal book.
Zeldman gave a great interview with Jared Ponchot and Jeff Robbins for the informatively Drupalesque Lullabot podcast. Not surprisingly, it's about web standards and the future of web technologies.
There's a very interesting discussion about responsive web design (designing the one thing for different platforms) and which is also the title of a book by Ethan Marcotte. All very exciting stuff (and I know, I'm a safe distance behind the bleeding hedge).
But I am still unsure of one thing: what is wrong with bloated markup?
This issue came up with the discussion on Adobe's Muse AKA “Web DTP for the rest-of-us”. No need to code, just bish, bash, bosh, and out come your designs at the other end, ready-rolled HTML and CSS.
Admittedly, the code is convoluted. Does this matter though, as long as it is accessible and semantically correct, and if you only ever use Muse and no Olde Worlde hand-coder ever need get their grubby fingers on it?
By way of illustration, compare the SVG code below left with the HTML produced by Muse on the right. I never hand-code my SVG image files, I leave that to Inkscape, vector illustration program extrodinaire. Likewise, does it matter if I never hand-code my HTML?
Twitter 
Linkedin 
ZDNet UK App 
Facebook 
RSS Feeds 
Newsletters 
Talkback
To answer "what is wrong with bloated markup?" as briefly as your question warrants:
1. Increased bandwidth costs.
2. Increased browser work.
Sometimes bloated markup also causes browser rendering problems, too. In my opinion, keeping things clean and simple tends to avoid issues altogether. The less complexity, the less chance for problems. I don't think bandwidth is as much of an issue any longer, even though it can make a difference for large corporate environments. But in that case, a web caching solution may need to be looked at anyway. No matter what way we slice it, bloated markup is very common now.
@aardrian: thank you for your succint contribution
"1. Increase bandwidth costs." Not that important.
"2. Increased browser work." Ditto.
The HTML weighs in at 33Kb. Even if this is 4x the amount of a hand-crafted HMTL, that is still only an overhead of 25Kb, which is *relatively* small (the images alone are 116Kb). Offset a slower download time against front-end artisan developer costs and it's obvious there are savings to be made.
Likewise, increased browser work really isn't an issue with modern browsers being updated and super-modified every couple of days.
@Jake: What about this gem from Elliot Jay Stocks on Twitter @elliotjaystocks:
"Design and test with real web type across multiple systems. Design and test with multiple browser widths. All impossible if you don’t code."
@Jake: And another gem for the record. Jeffrey Zeldman in Lullabot podcast
"I don't think it's possible to make a photoshop tool that thinks semantically, that thinks flexibly and fluidly." http://bit.ly/GoZeldman