ad_form supports and encourges mixing markup with tcl code. This makes changes to the look of the form, or the editing of the tcl file more difficult, increasing maintainance costs. Hopefully if the datasources don't change, you should be able to employ an html crew to maintain a site, but with ad_form you will probably need your tcl programmer to do the job.
Although it might be thought that having input of content and editing handled by the same form/tcl page, in actual practice I doubt it would be generally helpful. Remembering maintainance of current code, it is much easier to track down bugs if pages have a single function. In the event that the enter and edit pages become significantly different, the maintainer has to somehow perform a 'cojoined twin' type separation. I'm trying to imagine tracking down bugs by looking at the error log. What was the state of the form when the error occured on that page? Even with single function pages, errors that occur when users, not developers, visit a page can be baffling.
ad_form can't be used on a form where more than one object is being edited/input/deleted. This severely limits the usefulness of ad_form. These are things that simple html forms, and ad_page_contact handle with ease.
I think ad_form is more useful with admin pages, as there will probably be less mucking with the look of pages over time. However admin pages are more likely to have complex needs for displaying and editing data. Also, if absolute speed in churning out a UI is important, I think it could help quite a bit.
Of course the main problem is that I don't seem to be able to wrap my simple mind around the idea of ad_form. Maybe if the documentation would explain what vars are set and available in the adp page, based on the different parts of ad_form present in the tcl page, I could figure it out. If core packages are going to use ad_form this kind of documentation would be very important for future maintainers. Asking new blood to maintain a package using ad_form is quite a stretch.
