Me druthers
Custom datasets are evil. No custom datasets in my code thank you very much.
The alleged benefits of these abominations are
Point-and-click UI databinding is ok I suppose, but if you're going to remember what and where to point and click, you may as well remember how to code them up yourself - which gives you a variety of other options. For that matter you can do point and click UI databind with generic (standard) datasets if you use the IDE to create them at design time.
The really appalling thing about custom datasets is the heavy coupling they produce between code and database. The moment you use the horrible things, you get scads of nearly-unreadable machine-generated code that is incredibly sensitive to changes in corresponding database schema. Certainly there is IDE support for regenerating it, but firstly it can be difficult to persuade the IDE to notice the schema changes, and secondly when two people do this things can get very messy in a concurrent versioning system because it looks like they've both made elaborate conflicting changes.
Custom datasets may present dataset columns as typed properties but you still have to do type conversion to marshal values to and from textual presentation in editors, so explicit typing isn't the boon you might think. Typed values such as the Checked property of a checkbox can be handled directly, but these are by far the lesser portion, and require only casting. Custom datasets increase compile times and pollute the toolbox. If you commit to using them you end up with quite large numbers of the horrible things. This is bad because the moment you open a form designer the whole IDE locks up while the toolbox flickers madly.
Strong typing does give you static type-checking. To this I blow a big raspberry because trivial regression testing catches this stuff immediately, and it is very useful to be able to ignore it yet still compile and run while you resolve other issues.
Computed columns are a convenience at best. There are no circumstances under which they are necessary. If you want one because you are binding a grid and you want to display a derived value then be advised that you can do this quite conveniently in the IDE binding editor using a binding source. You could implement a computed column using SQL but this approach can severely hamper query optimisation. A binding source will recompute the value of a computed-column every time it is requested, and for every row from which the column value is requested, but only those rows.
If you're looking for somewhere to put custom logic pertaining specifically to the data, try the database. If you simply cannot live without some sort of post-processing then maybe it's time to write some stored procedures - possibly in managed code - or even start designing your data warehousing system.
The long and the short of it is that custom datasets are high maintenance with limited benefit. Best to ignore them completely.