This is the entity that the catalog revolves around and is used for browsing and searching. Product does not have any pricing information associated with it directly, but is available to the Product from its one-to-one relationship with a Sku (its "default Sku"). This one-to-one relationship is required, and Products cannot exist in the system without a link to a Sku.
This entity has pricing information associated with it and is sold and added to the cart. One way to think about a Sku is to look at it as a particular, concrete representation of a Product. Because of this "concrete representation", Sku has name, description, size, etc. Each Product needs at least 1 concrete representation of itself, which is why there is a required relationship between Product and its default Sku.
You can also have multiple concrete representations of a Product. Take an example of selling T-shirts. You might be selling a T-shirt with a certain picture on it: Let's call it a dog shirt. When you initially create the "dog shirt", you will give the default Sku a particular name, price, etc. However, you also want to offer this "dog shirt" in a variety of colors (e.g., blue, yellow, green) as well as a variety of sizes (e.g., small, medium, large). This would be represented by 9 additional Skus: A blue small dog shirt, a yellow small dog shirt, a green small dog shirt, etc. Each is related by ProductOptions and ProductOptionValues. A ProductOption in this example would be "Color" and "Size" whereas the ProductOptionValues would be "blue", "yellow", "green". In this example, a Product would then have 10 Skus related to it: 1 Sku that represents the default Sku (which is always required) and 9 other Skus represented by various sets of ProductOptionValues. This would allow you to have specific pricing (a blue XL dog shirt could be $2.00 more) and inventory constraints around each combination.
A Sku can also be a member of many ProductBundles, which is a subclass of Product. This relationship is achieved indirectly via SkuBundleItem where you can optionally set a discounted price for selling the Sku as a part of the bundle, as well as a quantity for how many of the Sku that you are offering in the bundle.
Orders are obviously critical in eCommerce. While a Broadleaf Order does in fact represent a completed order with its associated payment information, shipping information, and items, that is only a portion of its full functionality. In fact, an Order that is "in process" is actually a shopping cart that is modified as items are added/updated/removed. Furthermore, orders that are in the "named" state correspond to the concept of a wishlist.