On the scenario you are pointing, we can prevent users to duplicate parties by implementing mechanisms of name pattern recognition when they try to create from the Party selector.
We filter by default the Party selector depending on where it is being launched, for example, if it is a Purchase order we can filter Party by Category = Supplier and we can expose the filter in the user interface so the user knows what he/she is seeing.
Say they are tempted to create a new Party because they don’t see the one they are looking for, and it is not shown because it was incorrectly categorized as Customer and the Party selector is just showing Suppliers, by the time they type the name of the new Party, Tryton can warn the user stating there is an existing Party with the same/similar name, then user can remove the filter from the selector and show all the Parties, then they can realize that the Party already exists, its just it was categorized as Customer.
Categorizing Parties can bring more valuable functionalities, like create mailing lists to send specific messages to Suppliers, or Customers. This will enable the Parties module to behave more like a CRM
In general , from my point of view, a Party is an entity that interacts somehow with the Company and it could be a Supplier, Vendor, Employee or Bank, so the abstract concept as Party should be instantiated as any of the entities mentioned,