These are all manual solutions which require repetition of work. Also given uses can make their own changes in FAW those changes will not be replicated to the secondary site. Ther will always be additional legacy data in custom schemas and keeping two separate feeds for that is not a workable solution in this day and age. A dataguard based solution is the minimum expectation any customer would have for any kind of warehouse solution so I am afraid that though your response answers the question it does not provide a workable DR solution.

I.e this is how FAW DR is implemented, but unfortunately it's not fit for purpose of an enterprise warehouse.

This solution is not a workable solution because when we say customizations we are actually talking about custom schemas and having to pull that data twice from the various sources is not something anyone wants to keep track of. As I said before a solution that relies on manual synchronization of primary and DR in this age of automated DR and Dataguard will not be acceptable to any client.

So basically the DR strategy of FAW is tilted towards the idea that FAW only holds data from fusion and should not be used to hold stuff like historical information imported from the old EBS on-prem that was retired in favour of fusion. though there is a preview ebs adapter available there is no means to preserve this information in a DR site.

https://community.oracle.com/products/oracleanalytics/discussion/11097/faw-ebs-adaptors