If a web page needs some data, why not just have a SQLDataSource call a stored procedure? Why use an ObjectDataSource to call a business object that then calls the stored procedure? I understand that other apps (lets say desktop apps) built on the .net framework can access the business objects, but what if the application will always be only a web app?
To be more clear:
When should one use an SQLDataSource or ObjectDataSource ?
How does one motivate the choice ?
If you have a business layer that you're using in your projects, ObjectDataSource is the natural choice. This fits well with many ORMs, and many of them provide additional benefits (validation, undo, etc). It also lets you access any of the other properties & methods you have on your business objects - not just the direct SQL fields. This can come in real handy when binding - since it allows you to just bind to properties in the markup instead of having to write a lot of code behind.
If you are going this route, mixing SQLDataSource and ObjectDataSource can lead to confusion by the next developer to pick up your project. In this case, I stick with ObjectDataSource for code consistency.
If you don't have a business layer and are just hitting SQL directly - use the SQLDataSource. My personal preference is that all of your SQL code should be in a business or data layer, and because of I almost never use SQLDataSource.
Having just a SQLDataSource is perfectly valid, if it's just a demo, a prototype, or a quick hack. It's fast, it's easy, it just works and gives you the results you need.
However, when an app is designed and built for the long run, and anticipates that things (requirements, customer wishes, eventually the database schema), then it might make a whole lot more sense to introduce a proper "business" layer - model your business objects as objects, and then provide a mapping from the underlying database to those business objects.
As the saying goes - you can solve pretty much anything in computer science by one more layer of indirection (or abstraction) - same holds here.
SURE: you can go straight to the database, and sure, at first and for the first iteration, that's possibly (or probably) the quickest way. But in the long run, when an app is built to last, it's usually a quick-and-dirty way - the cost of upkeep, the cost of maintenance, the cost and effort needed for changing according to your and your customer's needs will grow and quite quickly, that quick'n'dirty solution doesn't look so great anymore, in terms of effort.
So to sum up my point: yes, initially, using a direct SQL Data source might be quicker and easier - so use it when that's the important point: to get things done for a quick demo, a proof-of-concept style app. But in the long run, when you look at the life span of an app, it's usually worthwhile investing a bit more (design and coding) effort to add this layer of abstraction so that your web pages don't directly depend on the details of the database underneath.
Marc