Okay, let me try it from the top:
Including the highest compatible version in the readme.txt is nice, but wouldn't it be MUCH better (and more secure) if when a major upgrade comes (say going from 2.3.3 to 2.5.x) that wordpress flags (and potential even disables) plugins that are not compatible or have not shown compatiblity with the new version? Perhaps even a simple pre-upgrade checker that would run through and let you know which plugins you will have issues with, so you can decide to move forward or not? Look through the troubleshooting forum, and you will see a ton of posts by people who got tripped up moving to 2.5.1 and incompatible plugins in the way, making the wordpress product all but die during the posting process (the issue was the sitemap generator). Had that been flagged as "not compatible" or "not up to date", perhaps more people would have found the answer directly.
I don't expect people who have lives to keep their free plugins up to date, that is EXACTLY why I suggested a simple system for checking compatiblity or "up to date-ness" of plugins. There are still plenty of links out there to plugins that haven't working since version 1.7 or so, that is a pure pain.
My problem with plugins during the post / edit / delete procedure is that many of them are not optimized or are using wordpress functions in a manner that really slams the server hard, especially on larger blogs. It is easy enough to make things work on a blog with 100 posts and 3 categories, but when you get to larger blogs (I have a couple that are past 10,000 entries) many of these plugins burden the system. There is enough code in wordpress that doesn't scale well (I manually add a couple of indexes to all 2.5.1 installs to make it run better), and these plugins just add to the pain. It is especially annoying to have something run on each edit that could easily be run once per day and generate very similar results. A sitemap isn't something you should have to wait to see run while you are posting (and on bigger blogs, this one can almost time out (60 or 90 seconds depending on your server settings). A true question of scale.
I can go mysql and delete a post (from even the largest db I have) in about 2 tenths of a second. If I delete a post using the wordpress interface on a larger blog, it can take a full minute. Is it a plugin? It is the code in wordpress? Is it a failure to properly index the posts database? Is other maintenance (such as category lists, parents, etc) being carried out with each post? It's not clear, because the lines between what wordpress does and what the plugins do it blurred.
Another plugins example of something that was a pain was a tagger function that added one click links for things like blogger, technorati, my yahoo, etc. I though it would be a very useful plugin, until I realized that the method it was using to add those tags to the posts also added them to the RSS feeds, with no method to remove them from the feed. They weren't in the wp_post data fields, but rather added for each post as it was called.
Unlimited access is all cool and fun, but it also means that many people writing plugins are either unknowingly using resource hungry procedures to achieve their desired result, or they are purposely bypassing what API exists to directly access databased and such, which in the end means they will likely fail at the next upgrade.