As the verb-noun convention suggests, I think that there are a lot of developers looking for a common way to join objects (lists), actually it appears a decennia old quest: as shows from the PowerShell Team Join-Object article and StackOverflow issues along with: In Powershell, what's the best way to join two tables into one?
Personally, I am convinced that a Join-Object cmdlet will generally result in a better syntax were an object (list) join is required (in comparison with alternative cmdlets along with Group-Object) and better performance (then using obvious iterators like ForEach-Object together with Where-Object or similar cmdlets and methods).
For that reason I am maintaining a Join-Object script/module for more than 3 years now. I don't think that my Join-Object version should be added to the standard PowerShell package (for one thing, it is written in PowerShell and not C# 🤔), but it might serve as an example for what I would expect from a syntax that comes together with a Join-Object cmdlet.

What do I expect from a "internal" Join-Object cmdlet?

• An intuitive idiomatic PowerShell syntax
  The syntax should be PowerShell like and include features similar to the SQL Join clause where it basically joins (a list of) objects or items based on related properties (-On parameter) or a simple side-by-side list join (by omitting the -On parameter) as a specific PowerShell cmdlet feature (see: #14732) .
• Ability to do similar Join types as SQL, along with InnerJoin, LeftJoin, RightJoin, FullJoin
• Ability to join based on multiple property relations, e.g.: -On Column1, Column2
• Smart property merging (e.g. if a properly is defined as related, it should only appear ones in the result)
• Respect the PowerShell pipeline (for the left object supplied through pipeline)
• A reasonable performance by using a binary search (HashTable) on the right object (knowing that it needs to be iterated multiple times).
  Also note the Linq Join-Object solution by @ili101
• Calculated properties
• ...