You can name your environments anything you’d like. The question is around what do we see as being best practice or common.
In most cases, terminology like dev, stage, qa, test, uat, prod, are understood. These are common names that can be found in just about every company that has development responsibility.
Consider onboarding new developers and you had to explain that private1-us → actually meant your development environment, or that pub-est-delta → actually meant your staging environment.
The naming is about maintaining consistency as well as simply naming your environments based on the role they play. When you see UAT, you know what UAT means. When you see QA, you know what QA means.
This also plays into the consideration of how open your API program is. The more open, the better. Building digital ecosystems that are easy to follow and understand without proprietary internal naming conventions, will help developers find what they need, and develop what you need.
Things like business unit names, or partners, private vs public, etc, can all be managed inside of your API products, or with access controls. For example, Partner A and Partner B could possibly see different API Products, but they would still access those APIs on the same environment. Business units would function the same way, where Team A only has access to API Product A and Team B only has access to API Product B, but both API Products would be on one environment.
My recommendation will always be :
2 Orgs — A Non-prod Org and a Prod Org. You might call them company-np and Company-prod
Where company is the name of your company.
Then on non-prod you would have :
dev, test, perf
And on the prod you would have :
mock, sb (sandbox), uat, stage, live or prod
Ultimately, name your environments with what those environments functionally are supposed to do. It’s the easiest to understand and manage.