Very Simple Business Object Illustration:
A simple dataset example would be a Buisness Object for Customer the has a method GetAllCustomers().
In this method code would be written to get db connection information and call a stored procedure or execute a query string (not a best practice) that gets the data from the db and stores it in a dataset.
Example Select * From Customers with a return value for the method being CustomerDataset.
In your application (say a WinForm app) you would create a reference to the business object (say Customers) and call the Customers.GetAllCustomers() method to retrieve data from the db via the business object.
Recall that the return value was CustomerDataset? This CustomerDataset can then be used in control databinding.

The real benefit, ready for this.... is encapsulation.
Recall how hard this was to understand in OOP?
The value in your applications is that you have an easy layer to use to reference main concepts.
These concepts (your business objects) are domain oriented and correspond with the things in the problem domain for your application (Customers, Orders, etc..) much like database tables.
Once configured it is a simple matter of calling these Business Objects' methods to get stuff done in your application. As someone earlier pointed out, this really assists with making you UI as dumb as possible.
After all how many times to you want to wire up data connection, data adapter and dataset calls in On-Click buttons. It is sooooo much easier to call a method of your business object from each On-Click to get this information from ONE place (the busines object).

Probably the best source for understanding Business Objects is digesting materials by Rockford Lhotka
1. http://www.lhotka.net/
2. Expert One-on-One Visual Basic .NET Business Objects APress ISBN 1-59059-145-3
3. Expert C# Business Objects APress ISBN 1-59059-344-8 (C# version of the VB book - pick your flavor)

He advocates remoting which can really be complex but that is not the most important part of these books.
He does a good job at presenting what business objects are and why they are a best practice way of developing software. A good part of the books are dedicated to solving problems in using multi-tier architecture effectively. He presents what a good design would look like for handling problems in using and designing business objects. Again, this material is not programming or .NET 101 but it should help turn on some light bulbs regarding the use of and creation of buisness objects.

One of the most difficult challenges is the mismatch between OOP in .NET (or any other OO language) and storage using relations (non-oo) databases. Datasets are one solution and Versant (which Dave Foderick mentions) along with other frameworks are a ORM (object relational mapper) framework.

Best of Luck!!!!
Keep swimming in the channel!