Leave it to me to revive all of the dead 4 year old discussions but.... It seems like the answer to the original question became a debate about speed. Does faster always necessarily mean "Correct?" Like shados says, architects should be focused on the cost of the application and how making speed a system priority can increase that cost. What about maintainability? What about flexibility? When your CIO comes to you and tells you your company needs to quickly adapt it's web interface, web services, business processes, and yes, ultimately, parts of your data model, or perish in an industry where your competitors have sexier and simpler web interfaces, more customer and supplier web services, cheaper and more streamlined business processes, and yes, ultimately, a better data model, what do you want to be able to tell him?
Typed DataSets are invaluable, but look through the pipe from the other end. All meaningful web activity starts at the UI. Your pages, web controls, user controls, codebehind, AJAX, etc, are all concentrating on displaying the data and controlling how the user interacts with that display. It shouldn't be bogged down having to worry about how to CRUD everything too, so of course you're going to want a layer separation there. Microsoft made it easy to be able to connect your databound controls (like FormView, GridView, DropDownList, etc) to ObjectDataSources that can bind with DataTables. However, when your applications grow in complexity, which they can rather quickly in the real world as user and management requirements evolve, this is not a good idea. DataTables and DataSets are a data access layer, period. Do you really want your UI layer connected directly to your DAL through a mere ObjectDataSource?
I came into .NET in 2005 from Java/J2EE, and the ObjectDataSource is the perfect device for hooking your UI into what we called a facade: a layer that hides all of the complexities of managing the data by wrapping operations up in specific method calls that each correspond to a system use case. However, that layer needs to operate on data objects to its job. How else could it deliver a complex object collection through a web service method? Again, do you want all of these client methods to have to create all of the TableAdapters and/or DataTables, optionally invoke SetXyzNull() umpteen times when adding rows, and manage multiple tables for one data object that is a disjointed specialization of another base data object (and all of its base classes)? It's rather easy and straightforward to wrap your DAL behind a taxonomy of data objects, what we called "POJOs", or Plain Ol' Java Objects, in J2EE. So instead of saying "new XyzDataTable().NewXyzRow()," it's much easier to say "new Xyz()." Then you can just call MyXyz.Save(), MyXyz.Purge(), etc, and use polymorphism to make sure the object's base data is saved into its (possibly separate) table(s).
What's more is you can use the same object model from codebehind if necessary, for example, when validating whether an entered value would create a duplicate (like when creating usernames). You can create and manipulate data objects on the fly from an event handler where using ObjectDataSources wouldn't make sense, and you still keep the DAL (TableAdapters, DataTables, etc) disconnected from the UI. Now that we have the UI interacting only with the facade and the object model, we get back to the DAL. What was the original debate? SQL-based TableAdpater methods versus stored procedures? Why would you want to put your developers through the tedium of creating 4 or more stored procedures for every table in your db if they could have VisualStudio do 90% or more of them in less than 1% of the time? I think it makes sense to have more complex, highly parameterized SQL (like advanced searches) wrapped in stored procedures simply because it's easier to open, read, and update a SQL file in Management Studio than it is to work with the SQL "Query Builder" built into the VS TableAdapter wizard. Keep your database people focused more on what triggers and constraints they need to have in place to maintain data integrity.
The only question now comes back to the subject of this discussion: do you want to allow the UI access to the DAL. If you do, you have a triangular MVC architecture. Otherwise, you can put the DAL in the same library as the facade & object model, mark all of the TableAdapters "internal", and you instead have a linear 3-tier architecture where the DAL is entirely wrapped up behind the "POC#Os". For it to be n-tier, you need to make sure the UI absolutely cannot access the DAL, or any aspects of the physical model. You want both the UI and the facade working with the "conceptual" taxonomy of data objects, which in turn encapsulate the physical table structures.
I guess, in other words, I agree with shados.