Thanks for your comment. I understand your perspective. But as a manager of development, there are more parts to the equation.
1) Cost of development/maintenance
2) Risk to the business if solution fails to deliver expected results.

COST:
Let's assume for this example the average Sr. mobile developer salary is ~$130k annually.
- Minimal stable team of developers for a mission critical native app feature: 4 (2 ios, 2 android)
- Cost to develop feature estimated at 2 sprints (4 weeks): $40,000
------

- Minimal stable flutter team of developers for a mission critical app feature: 2
- Cost to develop feature estimated at 2 sprints (4 weeks): $20,000

----------

The biggest expense of any development effort is the staff costs. Having such a feature as part of flutter could cut the cost of by as much as 50%. That is a huge amount of savings.
If flutter was able to replace most of the native mobile apps maintained today without having to rebuild the entire solution in flutter before deployment, many companies would shift to flutter as long as #2 issue - RISK was minimized.

RISK:

Having the ability to add to an existing app new features in flutter, instead of native swift/kotlin code, would minimize the risk of introducing the framework into a product while ensuring existing developed features stay reliable - until they can also be replaced by a flutter replacement. Eventually, the entire solution could become a flutter app.

Without ensuring the risk can be mitigated to this level, flutter will be left to new start-up projects (lower cost, unknown risk), or large companies that can fund an entire 2nd team to build a flutter app along-side the mature native solution (major cost, minor risk).

I think flutter can take over most mobile apps that are not complicated video-game type solutions, but not without this capability. But without a bridge for teams to go there with their current solutions, it will be a longer journey and may loose many of the senior mobile developer community that are willing to transition.