Some additional Pros/Cons

Pro

• Better use-case fit of tooling
• More general knowledge in the environment as opposed to somewhat routine-blinded framework dedicated knowledge
• Enforces best practices (generally consumable APIs, decoupled modules etc.)

Con

• Developers might need to learn new frameworks several times (new ones get added, people change products, others get deprecated etc.)
• Landscape architecture can be confusing
• Merging of products(/landscapes) is in the best case costly but in the worst case even impossible
• Interfacing architectures might not be compliant with other frameworks (e.g. product uses F1 and thus OData BE API, and this might not work well with F2)
• Culture is fragmented (F1-Developer, F2-Developer etc.)
• Analysis of all the available stacks needs to be done before each new bit and takes (more or less “wasted”) time
• Even though the report revealed that a particular framework is best, the result might still be inferior due to less experience/knowledge of the developers compared to another framework
• Architects and devs need to be super careful all the time to not create an isolated solution and might tend to overengineer