I always just use bare SQL with the System.Data.SqlClient.SqlCommand object, retrieve the results with a datareader and,... this was it. To be honest, I have never encountered a situation, where you need the more pompous ADO.NET approach with datasets, etc. What are the benefits of using datasets? How do they speed up development?

Being able to autogenerate and fill a DataTable from a SQL select statement in one line of code is pretty nice :)

I know you can do some cool stuff with DataSets and updates/inserts. You can move data into a DataTable with a select statement, modify the contents of the DataTable, and have the DataSet generate all the UPDATE/INSERT commands for you.

A query that returns a dataset (using ADO.net) can be optimized when handed off to the planning engine through ado.net.

Sql statements get analyzed every time they are executed.

You can also use a dataset to get just the updated records and not the entire "recordset." When you need constantly updated data this can be nice. In practice though, I have not used that feature of datasets very much. I don't like being locked into a certain way of doing things.

Ado.net will also package up your filters and queries a lot nicer for you. This will help you avoid the need to escape every character that is used or returned in a sql query. This feature by itself can make your program a lot more robust. For that reason I usually use the ado.net style (usually calling stored procedures) of query rather than sql statements, even though straight sql statements are easier to do.

They are also serializable so can easily be returned from XML Web Services, transmited via remoting etc and contain methods for reading and writing as XML, including Schema validation.

Personally for my game project I use them to store the Module data for ease of readability ( although binary data is stored within the dataset as B64 strings, which aren't to readable :) )

Basically the difference between using Datasets and a Datareader is that using the first one you retrieve your data once from the Datasource (usually SQL) and then you can work on the data without having to leave your SqlConnection open. Whereas the Datareader works only if you're connected to the SQL Server.
Also, Datareaders are Read-Forward only i.e. you can only read data and you have to navigate the result of your query from top to bottom.

Datareaders are great if you only need to retrieve data.
However, if you want your user to be able to Insert/Update/Delete records from the datasource, you would use a Dataset.
Indeed, you can modify the data in the dataset and then save them back to SQL without having to call the SQL Update statement yourself. There is an object called SqlDataAdapter which does this for you.

In a dataset you can have multiple datatables with their parent/child relations and their different constraints thus reflections pretty well the structure of your SQL Tables. You can query datasets thus returning only a subset of a result.

In the end it really comes down to what you need to achieve using your data. Datasets are not always useful. But sometimes, they can be your best friend.

I use datasets whenever I know the data will be changing. Ex. If I build a datagrid and allow users to change the data then submit it back to the database for the changes. I use a datareader if the data isnt going to change and will just be displayed. pretty much what the other guy said. :P