Leonid, as probably expected I will react. Le us do first is some environment clarification.

a/ Folders
There are not only two but many more system using folders.
- Metadata - which one as there can many versions setup (D T A P segregations)
- OS layers Server-side or Desktop-side visible with OS tools or SAS-tools
As the Desktop may be virtualized and the server can be part of a grid this can add more instances to care about placing and handling data/code.
Basically you have to think in three locations Desktop/Server and Metadata but some replications can add a lot to that. This is very confusing for intended users

b/ I always make a segregation in code objects and data objects.
+ Code types is going into version management (develop only = horizontal view ) and release management for life cycle management (ALM = vertical view).
The version management can be as easy being just only prohibit simultenous editting as the developers group is relative small and are being managed for their work (they are communicating).
+ Data types is not going into any type of release/version management often is must be kept segregated.
This approach is fulfilling all classical requirements of segregation testing etc. The normal programming and ETL development can be solved with this.
This for the business type of information as the technical building parts (eg SAS) have their own approach. This can be confusing as SAS is getting indicated as business application :<(

For self service BI and the analytics field this is resulting an other problem as they are needing the real production data and also are developing new reports/views.
With that requirement it can make sense to have two segregated "production: environments one where the development on production data is done and one where the approved results are placed.

c/ Multiple SAS environments. Let us keep that to environments as the multi-tier aspect (metadata web/mid data desktop) is used within an environment/level.
You have the following:
-i- The building in a environment of infra tools including the SAS and lay out structure for the business data/code. This can be done as a proof of concept.
This one will server as basic image for all other machines/evironments.
This will serve for all technical aspects including involved fixes to roll out.
-d- The Development environment for the business (code/data)
-t- The Test environment (system-integration) of what is delivered by developers
As these two environments are often used within the same project team it is possible to share the same same machine but the data/code and metadata must get separated.
-a- User acceptance testing is for validating bigger impacts before all this being deployed operational (p). Often a dedicated machine is required is one aspect can be performance validation.
-p- This is the operational business environment.
As previous being indicated it can exist of two (or more) environments.

All depends on the maturity level of ICT with business requirements/policies.