Some rules of thumb that help build the case for a DH (besides segregation of duties)
If you feel you need to reuse the data in other models
You need tighter governance on the master data
The transaction data is very sensitive (meaning only a few people should have access)
Your management team is willing to invest in the support of a data hub.
There are some "gotchas" though (my opinion only)-
Despite all the great benefits you must be prepared to have someone support it. That includes automation, audits, saved views, actions to build hierarchies, etc.. Don't underestimate the time it will take to have someone admin this. A good data hub will have a model architecture in a way that makes support easy - use best practices. Lots of articles on that.
You must be fully committed to keeping your spoke applications in sync with the data hub. This means you have to have a VERY good partnership with the modeling team for the spoke applications that they will not deviate from established lists and transaction data. You'd be surprised how many times I found people adding to lists or manually loading transaction data into the spoke apps (even with ALM - although that can help)
Remember, at least for now, there's no way to "push" data. You have to build the actions at the Target and (hopefully) with automation using preferably a CA certificate.
Invariably you will have to use a calendar for your transactions (see @rob_marshall definitive guide on transaction modules - quite possibly the best article out there). This then suggests you'll have to either maintain the annualization of modules OR you will have to contend with actions that prune your transactions as they become obsolete or your modules grow too big.
The time hierarchy introduces some additional challenges with your system modules or your output modules that don't use time as a dimension or are out of sync with the Target module in the spoke application. A little advanced but it's an inevitability which really brings us back to my first point, the support.
Lastly, avoid turning the data hub in to a data mart. While anaplan can scale to amazing sizes and handle the data sub-second, you want to avoid turning the data hub into the source for point solutions outside of Anaplan for non-planning data. That should be procured from a more formal data lake or data warehouse. Reasoning: you will have to build all kinds of interfaces and maintain them for non-Anaplan related activities. Very distracting and difficult to support!
Very good question and the answer centers around security and segregation of duties. 95+% of the time, we see data hubs in their own workspace as the owners of the data hub can be a different team, not always, but usually. Since actions can span across workspaces, having data hubs and spoke models in different workspaces is not a big deal and is recommended to keep the overhead of the workspace down.
We have a follow-up question if we keep data hub model and spoke models(Demand planning model) in different workspace. Let's say we collect 3 years of sales history into data hub to generate statistical forecast in demand planning model. It has consumed some space (Eg 2 GB). Should we also copy the same data into demand planning model again to generate Statistical forecast in demand planning model. If so don't we use double space to store the same data in different models? Please help to understand this better.
Only bring in the data at the level (granularity) you need into the spoke models. So, if you have transactional (daily level) data in the hub but only use Monthly level data in the spoke model, only bring that into the spoke model. Understand what data you really need for that model and what granularity and only bring that in.