Here Org1 framework can be maintained with genric flows and business rules, Client1,Client2...Clientn can be treated as divisions and can have seperate divisional implementations with their specific data.

My experience on building a similar project with similar approach you mentioned.Initially when we start we assume there is no workflow customization and over the period things will change and we tend to customize workflows or other artifacts at the implementation layer. Some of the pain points with this approach

1) if you allow workflow customization for each client then it will become difficult to maintain and need more dev resources 

2) Regression testing each client needs more testing resources.

3) Onboarding a new client needs Development  effort unless you build wizards to setup the client.

We re-wrote the same application after 10 years running the application in PROD with just building the framework layer and use ABAC to secure data , reporting and allowing little bit of customization like Correspondence

Curious what is meant by "just building a framework layer" yet deployed to Production? Then it would also be the implementation layer.

The original requirement sounds like a multi-tenant situation - Data separation within the same database. This is a possibility depending on your business model. The "boutique" business model can be appropriate for mid-size consulting firms. For example in the US there are firms that support boutique 401(k) retirement plans.

If security is the primary reason for clients wanting case data stored "separately" the client should be assured that Pega supports multiple ways to enforce data security such as RBAC and ABAC.  In the same database only case data would be stored separately, data classes such as assignments would still be stored in the same table.

In my scenario, yes you can call it as implementation layer because that's where cases are being created, but we call it as framework layer, thinking towards future of the our business if we have to implement for different regions / clients where there will be a significant workflow customization.

That is fine. Any implementation can potentially become the base/model/framework/template/blueprint/foundation for other applications.

You can accommodate customization within the same application as well. Either way the workpool class does not need to be changed

Perhaps case type specialization would meet your needs. Inheritance would also work in conjunction with DCR. Again, this can be done without changing the workpool class.

Pattern inheritance customization seems more straightforward and maintainable to me than direct inheritance when wanting to remain in the same application and workpool class.

You may have noticed that when creating a new Data Type in 8.1 App Studio, pattern inheritance is used to extend whichever base class you select after expanding the "Advanced" section. 

The assumption is that your backbone process is the same for every client.

You want to customize behavior at particular points in this process for particular clients, perhaps every client, i.e., the boutique business model.

The Visitor design pattern comes to mind. 

At each extension point in your process you can call VisitClient(Client, Stage, Step, WorkPage).

The caller is "WorkPage".  The callee is "Client".

The Client object observes that the case (WorkPage) is at a certain Stage and Step within its process.

The Client can then invoke its own logic against the WorkPage on its own behalf.

The question becomes:  "where and how is this done?"

One way is to use pattern-inheritance. The Client appends it's unique shortName to the WorkPage's pxObjClass then invokes rules defined within that pxObjClass.

The backbone process would be completely unaware that those Client-specific rules are being executed because it is not "in charge" during the "visit", the Client is.