I'll be blunt.
Personally, I find Apache Royale really difficult to work with. Using AS3 and MXML is fine, and that part mostly feels the same as it did in Flex and Flash. The big issue for me is that the Royale UI components have always felt half-baked. When I tried to build common layouts using the "Basic" component set, I was constantly being forced to write custom raw CSS and avoid manually positioning/sizing anything because there is no system for auto-measuring children in containers. Things that felt like bare minimum requirements coming from Flex that I'd want to see in its successor framework just weren't there (and, frankly, still aren't... many years later). I understand the philosophy of being able to include only the code that your app actually needs by using strands/beads, but I felt like the end result was that it never actually reached even near-parity with what Flex could do, even if you were to add every bead that is available, so it was always, well... too "basic".
I'll admit that I haven't actually tried working with the MX/Spark emulation components in Royale. They were still in their early infancy when I first became involved contributing to the Royale compiler. While they seemed to get a decent level of commits over the years, I never got a sense that they could be considered close enough to the original Flex implementations for me to want to use them. That very well could be my fault for not looking closely enough. Maybe they've gotten to be pretty nice to work with now. Still, I'm wary because, at the lowest level, they are technically based on the same "Basic" components that make me want to pull out my hair every time that I try to use them. Or maybe there are a ton of MX/Spark-only beads that never got ported down to Basic, so I missed out on them. I freely admit that I don't know enough about this particular component set in Royale.
I found that the "Jewel" component set in Royale is the most enjoyable and powerful to work with. Jewel components all look nice out of the box, and they seem to set better expectations for what they are capable of, and what they can't do. Or at least, the common layouts that I typically want to use are clearly available out of the box, with no custom CSS strictly required, and I didn't feel like I was hitting roadblocks almost immediately. I don't think that the auto-measurement I prefer was necessarily there, but I could still get things done (like porting the BlazeDS samples from Flex to Royale, which I originally gave up on when I tried it with the Basic components). Unfortunately, the contributor who spearheaded the Jewel components is no longer involved with Royale, and no one seems to have taken up the helm in their absence, so Jewel hasn't really improved at all in the last few years.
Obviously, I am biased because it's my framework, but I feel like Feathers UI provides a much more better developer experience, and one that feels closer to what it was like working with Flex. ActionScript and Haxe are very similar languages, so it feels a bit like latest Haxe is what ActionScript 4.0 could have been. XML layouts for Feathers UI are still pretty new, and unfortunately, they've taken a longer time than I would have hoped. However, things are finally starting to look promising if you want something similar to Flex's MXML. I just soft-launched MXHX, which I've been working on for a couple of years. It features center stage in Moonshine.dev, a project where I helped the Moonshine IDE team create a drag-and-drop GUI builder for Feathers UI.
I guess I could summarize my thoughts on Feathers UI vs Royale with a few quick points:
I think that Feathers UI has more UI components than Royale, and they're more feature-rich and stable.
Feathers UI has better cross-platform reach than Royale. It can be deployed to the web, like Royale, but it can also be compiled down to C++ native code for both desktop and phones/tablets (and I'm not just talking about an app that wraps an embedded browser frame... however, that is possible too, if you really want it!).
In spite of Royale theoretically having more contributors, I believe that Feathers UI development is much more active overall, with more improvements, and more overall stability/feature-completeness. The number of active contributors to Royale has definitely dropped significantly over the last few years. That said, I'll admit that I have also been a bit slower to update Feathers UI after the release of 1.0 too, but the big reason for that is because I joined the OpenFL Leadership Team, and I have been improving OpenFL's parity with Flash/AIR features and APIs (and adding new target platforms, like HashLink/C). Basically, even when I'm not improving Feathers UI directly, I'm improving its foundations in the other projects that it depends on.