While this is obviously true, it might lead to a short-sighted view. It strongly emphasizes the initial development of a solution and often disregards the ongoing maintenance of a project. I've seen many projects where the quickest (=cheapest) possible approach was choosen for the initial development of a feature but by this the effort for maintaining and extending the functionality was drastically increased. - Finding the right balance can be a tough call. Planning for maintainability and extensibility of a feature involves a lot of guessing the future.
Very true. My point was that the relative cost to create a relational database application around bound and unbound forms has to be included in any discussion of the pros and cons. That said, of course, short cuts and sloppy design impact both approaches negatively.
In fact, at the risk of going further than I should, I sometimes think that developers who come at the task from a coding orientation are more likely to ignore sound table design because they are confident they can manage it all with elegant code regardless of whether it's the most efficient design in a fundamental sense. That bleeds over into the bound/unbound discussion, but has primary implications in other areas.
To give an example that I recently bumped into in the real world, it's possible to create a table with repeating columns, such as "PartInspected" (yes/no), "PartInspectedDate", "PartPassedInspection" (yes/no), and "PartPassedInspectionDate" (date/time). Sound relational database design says that's redundant and inefficient and it opens the door for data anomalies. The developer who comes at the problem from the point of view of relational database design will immediately change that to two date field, "DateInspected", and "DateInspectionPassed", or one Date field and one Yes/No, "DateInspected", and "InspectionPassed". That allows you to simplify not only the interface, but removes the need for validation code to ensure that you don't end up showing the date an inspection was passed with a No value in the inspection passed field. Long winded explanation for a simple example, I guess.
My point is that, if you approach development from the point of view of the coder who sees writing that validation code as a chance to exercise their skills you are also more likely to lean towards unbound forms. If you approach development from the point of view of the relational database developer, you're more likely to implement a sound table structure that takes advantage of the bound forms' strengths.