"Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed."
Features, exportables, Strongarm (et al) are all compatible with the workflow you're describing. Our development workflow is heavily dependent upon branching. All new feature development takes place in branches that are later merged into dev, with stable "snapshots" taken from dev whenever we do a release. Pretty standard stuff, and we use features and installation profiles heavily in our implementation work.
"Suppose, in a Drupal project, you had two such features being developed simultaneously, and each added different new fields to a given content type, with corresponding changes to views and authorship workflows."
What you're describing isn't a credible workflow, it's a mess. Field declarations for a single content type strewn across multiple features? Why? Designing a content type and exporting it to code shouldn't take more than 30 minutes for even the most complex content types. If additional features are required they can be added to the feature but separation of concerns typically dictates that that code goes into a separate module. Cleaner that way.
"ssuming it were even practical for each developer on a Drupal project to have their own development instance of the database powering a site (which it totally isn't)"
All of our developers maintain local mirrors of the dev environments for all of the clients they work with. This includes snapshots of the dev database. Also, how is maintaining a local copy of a database either impractical or in any way a Drupal-specific problem? Any project that includes a datastore is going to have similar issues.
"The exported blobs are pretty much opaque to many Drupal developers (or non-developers, as you say), though, and may not be expressed sufficiently sanely that Git could figure out what changes actually took places. When these features were ready to be merged, would the merge work? Who knows? What if there were merge conflicts? Would developers be able to resolve them? Worse, what if Git's notion of the correct merge strategy didn't actually produce a semantically correct result?"
Merge conflicts happen with any workflow. Merge uncertainty is an issue with revision control, regardless of what platform you're developing in. As far as manual merges goes, I submit that any developer should be capable of manually merging simple array declarations (because that's all exportables are).
"All of these operations take place on generated code that nobody wrote and nobody reads, which is scary enough that the whole process wouldn't be trustworthy."
I think our definitions of both "code" and "trustworthy" differ greatly. Exportables aren't huge blocks of opaque logic. They're simple associative arrays. I have no problem trusting code that generates array declarations and has been tested by the core project devs, security team, module maintainers, and several thousand developers on tens of thousands of websites. Your mileage may vary.
"Exportables are yet another in a long series of efforts in the Drupal community to attempt to address a deficit they have with respect to most other web stacks, and again they've done it in a way that doesn't really deliver the benefits of the feature as it exists elsewhere"
100% accurate, you'll get no argument from me here.
"database abstraction layer"
My kneejerk reaction when this was first announced: DBTNG is a fucking travesty foisted onto the community by Acquia as part of a corporate play for the "enterprise" market. After a year of screwing around with it: It still a pain in the ass but with all of the bullshit going on with the MySQL project courtesy of Oracle, this might turn out to be very very useful.
"object-oriented design"
Who claimed Drupal was object oriented? Seriously, I'd like to know so I can spill my drink on them if I ever run into them at a DrupalCon afterparty.