Hi. This really depends on your requirements, and there is no right and wrong way. Some design choices meet some requirements better, other choices may meet other requirements different.
The general advantage of the product as a page is that is has all the page behaviour, out of the box. This includes products that are versioned, products automatically having a URL, you can look at differences between current and old versions, permissions behaviours out of the box, etc. There are advantages to this structure. There are also disadvantages, such as a potentially very large site tree, which may or may not be a problem. E.g. if the products are hierarchically organised, it may not be a problem. But if the number of products is going to grow to 100000, it may become untenable.
DataObjects give you more potential flexibility, but you may have to do more work to get the behaviour you want. You can write a controller that surfaces each product with a URL segment. If you have a very large set, or a set with little inherent structure, then DataObjects are usually a better way to go, and there are things like ModelAdmin that assist in giving you an interface to work with those objects, as well as third party modules like DataObjectManager, designed for this purpose. Bear in mind that quite a bit of Page's functionality comes from decorators, like Versioned, which you can apply to DataObjects. Again, it's flexibility and control, at the cost of more effort (in my experience, anyway)
If your site is already implemented using pages, you probably only want to undertake moving to a DataObject model if there is a clear advantage to doing so. e.g. if performance were unusable with pages for some reason, or it looks like it might not scale to a much larger product set if that is planned. There is a cost/benefit calculation behind this.
Mark