The memory overhead you see does not stem from spine-flutter, or to be more precise, the underlying C++ objects. That is the same as for spine-ios, which also uses spine-cpp under the hood. What you see there is simply whatever Flutter's engine needs to run. Also make sure you are using a release build not a debug build for profiling. I'm pretty sure Flutter in release mode does not use 250-300M.
Regarding CPU usage/performance, Flutter's general purpose FFI can simply not be as efficient as Swift/ObjC code directly calling into C/C++. There is absolutely nothing we can do about on the spine-runtimes side.
The only alternative to this would be to port the Spine core APIs to Dart. I can guarantee you that the result would be worse, Dart's AOT compiler not withstanding.
You can also not compare spine-ts Canvas backend with the Simple Animation example in spine-flutter/spine-ios. spine-ts Canvas can not render meshes, only rectangular image regions.
