Um, your point is clear, but I can't say that it reflects all plugin authors.
You do bring up some valid points, but there are other logical options as well.
First, you should keep in mind that mu-plugins is a very "special" type directory.
99% of plugins don't need to be in there, as they should be in the standard plugins directory instead.
Only plugins which must be loaded on every blog, and for every single page load should be in there.
If it's something a user may/may not want, it should be in /plugins/.
Using $wpdb->table is the proper way to go about it.
That way all tables from a plugin are correctly associated with the proper blog. Unless one "really" needs a global table (like SK'2 blacklist, for example), then only would you need the true table prefix. If you need the blog id, then there's a variable for that available ($blog_id).
Granted, in this plugins case, I can't specifically see it being needed. If you want a different table prefix, for example something like my_plugin_{blog_id}_table-name, it just isn't something you want to do in MU. You'll wreck folks blogs with a quickness. Especially if those blogs are scattered over multiple database servers.
While there are some aspects of the WordPress documentation that could be better, you have to admit that honestly their Codex should be a role model for other projects. Again, there's always room for improvement.
When it comes to MU, it's 98% WordPress. Yes, there's differences. But, most things still work as intended.
When a plugin needs activation, simply checking for an options existence is far easier than hooking into the activation process.
if ( !get_option("my_plugin") ) {
install_my_plugin();
}
Always easier to do that, IMHO, regardless of WP or MU since who knows, that plugin activation hook may be subject to change in the future. But, the widely used get_option function is likely to remain the same for quite some time as it's heavily used in the WP core.
Whether that's just a single T/F entry in the $wpdb->options table, or maybe a version number or something, it's (again, IMHO) a better option to hook into.
If you need a "sitewide" table, like users for example, $wpdb works just fine.
"Most" plugins which are, or could be, common to WP and MU won't need to mess with table prefixes, or with global tables. They concentrate on a particular blog, vice the system as a whole.
Although there may be a need for certain sitewide admin options, which can be tacked to the Site Admin menu, and use get_site_option() for storage. Those are rare cases though.