3) Forms are not data. Forms are presentation of data, and input of user data before it's massaged. In many cases, that differs from our model considerably. Making Forms API into Data API means that we bolt ourselves to a 1-1 field/column sort of relationship, or commit to ugly hacks and workarounds. In the old days, the node edit form used $_POST['edit'] to create the node object directly -- cast to an object and go! :-) It's a good thing that we've moved away from it.
I'd like to pick at this point specifically. While I agree that forcing developers into a 1:1 relationship between form elements and db columns is bad, why not start with that as a default? Given a data definition that is 1:1, Drupal could do the hard work of storing that data, leaving the programmer to work on other things. If the programmer needs something more complicated, he/she could certainly register a "#callback' on the data element which did the appropriate validation and storage. Taking this one step farther, modules could register new data definition elements, like the various field modules do right now for CCK. If the '#type' is 'foo-bar-baz', we could look up the foo-bar-baz symbol in some sort of vtable and call the appropriate function. (Forget the days of "drupal is a framework", and welcome the "drupal is a compiler" era). Again, we already have a DDL, let's use it. -M