You mean with respect to accessing specific type information at runtime?
Using the -final build flag (eg: openfl build cpp -final) can greatly optimise your output code, stripping out unused code, debugging code and reflection features. It’s these cross-platform reflection features that provide type detection, but they come with overhead.
So where possible, I try to avoid using things like reflection and be careful with dynamic objects. That can be difficult at times, like if you were needing to differently handle multiple possible data types through a single function. I touched on this issue with you previously.
I have used Unity for some projects, but that’s going back some years. Back then (2016-2018’ish), I noted the output bundle was considerably bigger than Starling for AIR’s, and had more GPU compatibility quirks than Starling for AIR on desktop targets. Unity development was also complicated by Unity updates, which often introduced breaking changes to a project, causing everyone to have to sync to a specific version of Unity for the duration of a project. Whereas dropping in an updated AIR SDK or Starling framework was largely trivial.
In comparison to Starling for AIR, I personally found Unity bloated, expensive and bound by restrictive licensing. Despite its cost and bulk, it lacked the fullness and richness of features the free AIR SDK provided, instead relying on sometimes questionable 3rd party add-ons, with inconsistent implementations. Developing in Starling felt highly streamlined by comparison.
I’ve dabbled in UE, but nothing really worth mentioning. Godot has interested me for a while, and if I was to pick one of the three, that’d be my focus, but that’s primarily because of my leaning towards open-source projects.
If you’re looking at that sort of engine though, then you might also take a look at Heaps.io. This is the game engine made by the folk who make Haxe.