Being an interpreted language that is bandwidth restricted, the use of massive code libraries to 'simplify' writing pages is the antithesis of efficient coding.
The "king" of this type of nonsense is of course jQuery -- the laugh being that most of the stuff people do with jQuery really has no business on a website, and the rest tends to be stuff that would be smaller and more efficiently coded WITHOUT IT. Much as I see no benefits to HTML 5, the handful of tiny benefits offered by jQuery are vastly outweighed by the disadvantages of extra file handshakes, slow page loads, processing overhead and delayed rendering of the page, and taking something simple -- delivery of content -- and making it several times more complicated than need be. By itself COMPRESSED jquery is half the size I allow for an entire page template -- that's HTML + CSS + SCRIPTS + IMAGES... and uncompressed it is many times larger than that. When you end up with 50 to 200k of code on a website before you even start plugging content into it, YOU'RE DOING IT ALL WRONG!!!
.js for nothing and your scripts for free. That ain't working, that's not how you do it. Lemme tell you these guys ARE dumb. I want my... I want my... I want my PHP.
Quite often these days I'm seeing people wasting tens or even hundreds of K of scripting on pages where I'm stuck asking "FOR WHAT?!?" -- sometimes it's for things I wouldn't waste more than two or three lines of CSS on, sometimes just "pageloads are evil" idiocy, other times it boils down to outright ignorance of what should be handled server-side and what should be handled client-side... More often than not as I said under Section 3.1, it is just for goofy animated crap that does NOTHING to make the page easier to use.
3.3 AJAX replicating frame behaviors
There is this crazy idea right now we're seeing of people being obsessed with the idea of 'pageloads being evil' and how AJAX is being used for things like tabbed navigation or to avoid redrawing/resending markup. MAYBE if your markup wasn't a fat bloated steaming pile of crap it wouldn't be an issue.
Almost universally the people pulling this particular stunt have that fat bloated code I mentioned above with endless pointless wrapping div, endless pointless unnecessary classes, scripting libraries, and a whole host of other things that really should be pitched in the trash. THEN they go and throw even MORE pointless code at it to... wait?!? SAVE BANDWIDTH?!? Sorry, when you have a fat bloated slow poorly written website, THROWING MORE CODE AT It IS NOT THE ANSWER!!!
AJAX can be really useful, but it is NOT the be-all end-all solution and quite often pisses all over accessibility, functionality, ability to be indexed properly by search engines, and a whole host of other shortcomings. If you are writing a genuine application akin to Google Maps or Google Docs, knock yourself out. Same goes for things like convenient submits of posts to forums or responses to blog topics. But if you're just writing a flat website of normal content, all you are doing is wasting code on a total non-issue and destroying the accessibility, functionality and speed of your website.
Really if you have so much 'extra markup' around your content that wasting a hundred K or more on AJAX and scripting is 'saving' you anything over a full page-load, your code is absolute rubbish that probably needs to be started over from scratch. It's the equivalent of treating someone who jumped on top of a live grenade with Band-aids and Bactine.
Admittedly, I say the same thing about whitespace stripping and script compression -- if you see measurable benefits from it, you've probably got rubbish code. At best it's a lame way to squeeze performance out of bad code, at worst it's sweeping deep rooted issues under the rug.
... and a LOT of users are intentionally blocking scripts, see the popular 'noscript' plugin or Opera's in-built per-page script blocking.
3.5 Static scripts inlined in the markup
If a script is the same on every page of your site, putting it in the markup means it has to be transmitted every time you access a page -- even the same page if the contents are updated frequently (like on a forum index). Putting it into an external file allows it to be cached across page loads reducing the bandwidth and loading faster overall, even if it does introduce a minor delay during first-load. Usually that first-load penalty is better addressed by NOT using a dozen separate script files, a dozen separate CSS files, or dozens and dozens of images to do the job of a fraction that.
3.6 Tracking Scripts
The past five to six years really people have become ridiculously obsessed with tracking information. Much like the nonsense spewed forth by SEO scam artists, it often ends up the equivalent of pouring shellac over a pile. No matter how much you polish it...
If you REALLY want more information, use just ONE -- probably Google Analytics -- but to be frank, if you are worrying about more information than can be gleaned from log analysis tools like Webalizer or Analog, you're probably wasting time worrying about data that has NOTHING to do with the health of your website... and that's time better spent making unique content of value so there's a REASON for people to visit.
3.7 Supplanting form functionality
Vary from that and you're pissing away any chance of accessibility, probably opening security holes if you're not paying enough attention to server side handling, and possibly making it take MORE bandwidth (despite wild claims to the contrary made by script-tards) as you spend more bandwidth sending the extra code than you would if the form was built properly and clearly labeled.