This is a similar discussion I've been considering on something we are currently building. Typically another scenario is adding data directly to the Product item for them to configure and then you would pull using the context item. Although in that approach you would also still want a datasource reference, so that things could be personalized or A/B tested etc.
Which approach you end up taking depends on a lot of factors and doesn't necessarily relate to a good question on Stack Exchange because its opinion based. However that's not exactly what you asked. So the question is can you add product data to product page item (I'm assuming you mean a page type template called product page). Absolutely, but not directly. You should define interface templates (which are defined in the foundation/feature layer) which then your page type templates would inherit from.
Also if you went with your first approach where you have datasources that are specific to a product, then there again you would define a datasource template (at the project layer only) and optionally you could also define folder templates (any layer) to organize your datasource templates. Those datasource templates just like page type templates wouldn't contain any fields directly, but instead inherit from interface templates which would be defined in the various modules in helix based on their functionality.
The only issues with this approach that I can see, is if you have renderings that might have datasources located in multiple locations, you would either have to customize where it pulls those datasources from or just not specify a datasource location on the rendering.
The second approach you described benefits because you can have one data source shared across multiple renderings. The only issue which you need to decide based on your architecture, is if it even makes sense to do that. Example, a product model number shared across multiple renderings, probably doesn't make much sense. Whereas a Section Title or some form of Ad, very well might make sense. You could always vary and do both approaches as well. Using this approach for the datasources that are shared, and then renderings that are specific to products, to use the local children data source approach.
Also one thing to note, is yes your content tree shouldn't be extremely confusing for content editors, but it should always be logical, so yes it might require editing items in another part of the tree with the content editor, but I wouldn't base this decision just on that. Especially if your content editors are using the experience editor, they wouldn't really know where all of the datasources exist inside of the content tree.
You should follow Helix best practices with template types and how each type inherits or is used in specific places in your solution: http://helix.sitecore.net/principles/templates/template-types.html
