Code
You’re going to have to translate your code no matter what. However, since you’re starting from ActionScript, it will be easier to translate.
Also, if you’re familiar with Flash’s display hierarchy (parents and children), it’ll be easier to get used to OpenFL than Unity.
Code performance
Both Haxe and Unity produce fast code, but I think Haxe has the edge.
Unity’s code is “around 20 times faster than traditional javascript and around 50% slower than native C++ code.” Haxe, for the record, produces C++ code when you compile for Windows, Mac, Linux, Android, or iOS.
AS2 was really slow, and you still made the game work. AS3 was, depending on who you listen to, anywhere from 2x to 10x as fast. OpenFL and Unity are both faster than that.
Art/animation
SWF assets in OpenFL have improved over time, or so I’m told. I’ve never actually used them myself.
If they still don’t work for you, you’re going to have to use sprite sheets. Unity supports this natively, while OpenFL requires slightly more setup (downloading a library).
Unity has a visual editor to help you import a sprite sheet, but OpenFL is even better. Flash CS6 can export sprite sheets in the Sparrow format, which OpenFL can import directly. (If you don’t have Flash CS6, you can use TexturePacker instead. Both OpenFL and Unity can import TexturePacker’s files.)
Sound
If you didn’t like how sound worked in Flash, you probably won’t like it in OpenFL either. Unity’s sounds are a bit more convenient.
Actually, hold on. Did you play sound by putting it in a movie clip and then playing that clip? Because in that case, OpenFL is different than what you’re used to.
Rendering performance
OpenFL uses GPU acceleration already, so you shouldn’t need to use Starling. I’d guess that Unity has better rendering than OpenFL (with or without Starling).
That said, your game worked without GPU acceleration, so all of these options should work even better.
Tutorials
Unity has more tutorials.