Why are distinct classes necessary for Customer and Account in the design of the Amazon Shopping System?

I've been studying the low-level design (LLD) of the Amazon Shopping Website on Educative. In this context, I've come across two classes: 'Customer' and 'Account' (details provided below). Could someone offer insights into the reasons behind keeping these classes separate? How is this approach a better design than having a single class that combines the information from both?

Definitions

Customer: The Customer abstract class refers to a user trying to buy a product from Amazon. Hence, it can access the items present in the shopping cart through the getShoppingCart()function.

Account: The Account class accesses and showcases the personal details of the authenticated user and the admin, who are the two types of registered accounts available in the system. Users with an account will have the option to add and access multiple shipping addresses as well as add and delete different products and product reviews.

Class Diagrams:

Customer

Account

I am unable to figure out why this design is good

Welcome in the wonderful world of separation of concerns:

• A Customer is someone who buys products, whether it's on the website or not.
• An Account is someone who connects to the website, whether it's a Customer or not.

Of course, most (if not all) Customers have an Account. But not all accounts correspond to customers. For example:

• The admins of the system are not customers. When they connect they will not have a shopping cart, but need to perform some admin functions.
• The vendors may also have an account. Again, not for shopping, but perhaps to access some stock keeping functions.

This is a domain reason to keep both separate. In this regard, the design has a little flaw: an admin would not have a shipping address. Moreover a shipping address without identity is useless. So the address should be in the customer.

Another domain reason is that a same Account may have multiple "roles" so that one account is associated to more than just a customer.

There are technical reasons as well: if you would merge Customer and Account, you would have to duplicate the password management features for all other classes representing people who connect to the system. This would go against the DRY principle. And if later you'd realize that everybody should connect with SSO or with 2FA instead of simple passwords, you would have to change not just a single Account class, but all the other classes managing passwords as well.

Remark: you do not need to add "extend" next to the inheritance arrows (that are anyway recognisable with their big hollow triangular arrow head). This is not required by the UML standard and just adds unnecessary redundancy