Anyway, I am always very happy to see OSS projects like that making a living of paid services (or the opposite, whatever ;) ).
Disclaimer: original ansible author here and I run engineering for AnsibleWorks. First off, ansible itself (which this post is about) is text based. I assume you're talking about AWX, which is coming out shortly in 1.4 form, which is our commercial server -- UI and REST API. (Ansible core is decentralized and doesn't even need a server installation).
AWX is designed around team workflow and wants to be the central hub around your automation tasks. i.e. how do you control who can access what, who's doing what, and make things push button in the hands of people who might not be the ones writing the content. You can delegate the ability of lab staff to manage inventory, but not allow them to deploy software, or let them only deploy specific projects, etc. Same for Dev vs QA vs Ops teams, etc.
I definitely don't think it's something everybody needs, but it's available for those that find it useful, and definitely recommend everybody try it out. In the last release, we added some nice source control integration features so you can still develop in your editor and retain the ability to have the web console and central logging. In the upcoming release, we do some neat things with graphically syncing cloud inventory and provide some bonus console information that is useful if you are working with teams who want to know what's been going on where, and it improves the ability to quickly drill down and see what parts of your infrastructure might need attention.
One of the other features is it's ability to hold onto credentials, so you can share source control, machine access, and other credentials with your team without them needing to actually know those credentials.
If you remove someone from LDAP, they can cease to have access.
Anyway, it's super important that we don't hold ansible core back, so what's going into the product is largely around team workflow, and things that automate workflows in Ansible, just like how Ansible automates your system. It's intended to be able to hand Ansible to other people -- and work better in your overall team context, even people who don't want to be writing playbooks. If you're a 1 or 2 man shop, you might not need it, but try it out anyway and let us know what you think!
Also, here's a blog post about the 1.4 Ansible release, which explains the changelog at a bit higher level:
http://blog.ansibleworks.com/2013/11/21/ansible-1-4-released...
I can't speak for the UI, but I use Ansible to deploy everything. It's been a joy and a lifesaver. I just used it to provision a new server (from zero to full Django stack) in 30 seconds. Fabric will accomplish the same things, but Ansible is much more elegant and terse (by a lot). I definitely, definitely recommend it.
For the UI, we use either ansible-pull or http://www.getinstabot.com, which is a chat room assistant I'm working on in my spare time. Being able to say "instabot deploy feature/discounts to staging2" and have the code running there in ten seconds is fantastic, and only possible thanks to Ansible.
Some things are easier to do: builtin templating for things like config files is nice and all the modules I've used work as advertised. Some things are harder: reusing groups of similar tasks is kind of awkward but doable. The main advantage is that the ansible imposes a structure that is necessarily self-descriptive and that makes everything very readable. The docs are great and the learning curve is pretty linear so you can defer messing with advanced features until you need them (at that point you'll probably be happy they exist).
Curious on thoughts about what we could make easier.
Thanks very much!