One structure vs a structure per section?
TL;DR: Let the content dictate how you model and architect it.

If the site is sufficiently small or sufficiently simple, I think either approach is ok. My team has used both approaches, and it really depends on the Client's needs.
An incomplete list of reasons to use separate channels and structures are:

Tagging/Categorizing things like Products is probably easier to manage when they are in their own channel
Your client has multiple divisions and they are managing their content separately, and thus need to control permissions
You want to reference content pieces in multiple places

An incomplete list of reasons to use a Site Pages approach are:

The content isn't highly relatable, or doesn't rely much on relationships/categories/tags
The site is small enough
The client has demonstrated an ignorance or apathy for understanding content and &quot;just needs a site&quot;
Project management constraints: fast timeline, cheap budget, or pain-in-the-ass-go-away clients.

If you're familiar with ExpressionEngine and channels, then you probably know that things don't have to be pages to be in a channel or structure. You can combine the two approaches for a slightly sophisticated site.
Here's an example we have done that uses both approaches:

We used structures for things like Executive Team Bios that appear on one page. The landing page is in the Site Pages structure, which supports 3 levels max, while the bios themselves are managed in a separate structure (a channel would have been fine here, but the structure allows us to order by rank without an &quot;order&quot; field). We put a Management Widget blockType in a Matrix/Neo field so the user can put that content where they need to. That block allows them to select &quot;Management&quot; or &quot;Board of Directors&quot;, so the block is reusable on multiple pages.
This block could have easily been a nested block using Neo/SuperTable fields, but the categorization (Management/Board) is what led us to make it it's own structure. Some members belong to both groups, and without the relationship it would have required inputting and managing duplicate content.

If navigation is your concern, you can use plugins like Navee or A &amp; M Navigation to allow content managers to build navigations. Or on smaller sites, we just have a &quot;Navigation&quot; global field group with entries fields, and users can build out header and footer navigation as they deem appropriate.
My advice is let the content dictate how you model and architect it. If you have complex content requirements, don't try to shoehorn them into a one-structure architecture. Craft's CP allows you to group channels and structures, and the Expanded Singles plugin allows you to put singles in the entry sidebar. This can help content managers know what they are editing while allowing for more complex models. See below: