On a side note, why do you feel you need to create your frames via xml, for an Ace3 addon ? Do you intend to use/support any specific convention or template ? Kind of hard to provide a meaningful response, if you don't describe what you hope to accomplish.
Why do you need your addon(s) to be using the Ace3 framework, if they are working just fine ? Flexibility is a term open to different interpretations. Are you using a modular approach and thus require AceAddon-3.0 ? Do you usually have issues with hooks and scheduled timers ? Do you require configuration menus and/or localization support ?
I guess my point is, you need to determine if there are specific areas in your addon(s) that usage of the Ace3 libs would provide a meaningful, tangible benefit and work towards using the libraries that you really require, rather than just porting the addon for the sake of making it "Ace'd".
That's a wise indeed, but I just want to try myself and check why those lots of people are using ace. It seemed to me that the easiest way was "aceing" my addons since I already now how they work.
So that's pretty much all.
Why I use Ace3? - To try it, and because working on top of a framework is usually really useful.
What's my problem? - I weren't sure how Ace users create UI
Personally I try to stay away from UI elements and frames, but to my knowledge very little is done around them in the ace community. There are however certain libraries to help accomplish certain tasks. Such as LibCandyBar-3.0, which will provide you with a means to generate a timer bar. Which requires LibStub, and CallbackHandler libraries as a dependency.
As with most frameworks, the general purpose is to ease the task of commonly used functions from the native environment, with as little overhead as possible.
The downside to this is that several commonly used functions are generally wrapped into 1 particular module. So depending on your needs for the framework, you may end up increasing the size of your addon and re-writing a large portion of it, to do the same exact thing, and have several portions of code remain that are never used.
To further elaborate, depending on your needs for the UI, the majority of Ace addons I see/use, rely on the native ability to create frames in both xml for templates, and lua for dynamic functionality, such as dynamic drop downs, or population based on user events and variables unknown until an event occurs to generate the frame,button,data,etc.
I haven't seen any WoW Script IDE that will generate frame elements via LUA. I believe this is due to the nature of how most IDE's interpret rendered code.
Since most frame elements are wrapped in functions, and are called for onEnable or onInit, or onEvent, the interpreter would also need to be able to parse those functions/events to generate the frame correctly (from a coding perspective) From a pure design perspective it's possible, but would not enable you to code around it with out becoming a very bulky IDE like visual studio, that's why Visual Studio is so expensive of an IDE.