Good question. It can't do anything that Selenium can't, but it's a lot easier to work with. It's like developing in Assembler vs developing in C: Both are equally powerful in what they can achieve, but the former is much more technical to use than the latter.
The analogy extends further: We were invited to write an article about Helium in the December issue of Professional Tester (professionaltester.com) in which we compared automating Gmail with Helium vs pure Selenium. The code with Helium was 66% shorter, but ran on average 26% slower than an (optimized) Selenium script. You can find a thorough analysis covering the differences between Helium and Selenium here: http://heliumhq.com/AutomatingGmailWithHelium.pdf
Interesting. We have a ton of work put into Selenium already so switching costs would be rather high for our team. But probably worth keeping an eye on this project.
You're going to have some big obstacles to overcome trying to get people to pay for this versus using Selenium.
Just would like to comment that you wouldn't have to "switch" completely. Helium is fully interoperable with Selenium, that is, you can freely mix calls to Helium to calls with Selenium. So in your case, you could add the Helium library to your project and when you extend or maintain it, at every step, choose whether you want to perform a particular step with Helium or Selenium.
The analogy extends further: We were invited to write an article about Helium in the December issue of Professional Tester (professionaltester.com) in which we compared automating Gmail with Helium vs pure Selenium. The code with Helium was 66% shorter, but ran on average 26% slower than an (optimized) Selenium script. You can find a thorough analysis covering the differences between Helium and Selenium here: http://heliumhq.com/AutomatingGmailWithHelium.pdf