Ah, I understand now.

yes, of course, you need a JOIN ; and you think that all these necessary joins will affect performances, and increase complexity in supporting.

But in your example, what happens when data is modified in natural key 'CompanyCode' of parent table 'Companies'. You need to update all child records in table 'Employees', and you probably have coded a trigger on that purpose, or even better, an constraint with on update cascade (trigger is procedural, and slower than declarative constraint).

With a surrogate key, you will never update child tables, but only one record in parent table . Keep in mind that writing on a physical disk (what you need with an update) is always slower than reading from memory (and your view will be in a cache plan in memory, if you have good indexes)

And the more you have foreign keys in the child table, the more performances are increased with surrogate keys.

Additional maintenance effort in preparing views? not sure. IMHO, less effort in development (both on server side and client side) and in maintenance.
as an example, let's say tomorrow you need to get company name with employee (new requirement of your main customer ). You will need a view, ok? So, why not having this view today, and simply add a field from 'companies' table in it. Views bring you scalability.

Your example is about normalization. A company code should be part of the company record in the company table. If you store that code again in the region_office table you do not have normalized data. If you have twenty tables that use the company code, you have twenty things that are going to break when the use decides to change the company code system. If you are using the company_pk as the company_fk in all the other tables, he can change the data he can see ( company code) to anything he wants in one place - the company table - and every region_office screen etc will show the correct company code.



The joins you need in meantime are annoying, sure, but it really is better design. In SF you can make pulling those related values (company_code) part of the SQL select or sproc that gets the data and then use a custom field property to give you a strongly typed property.