What do you like best?
I like most the Github integration part of Travis CI. When you have an existing Github (either open source or closed source) project, it can work seamlessly with the existing structure and integrates on 1-click without almost any effort on your part. The only thing that you need to add is a configuration file, which is usually very well documented in their docs and also shows the whole log of what happens during the build, so you can catch your mistakes easily.
What do you dislike?
Travis CI is essentially a linux only CI. They say they are working on supporting Mac as a platform too, but due to the nature of licensed products, I dont think it will be free to use for open source projects like the existing one.
It doesnt seem like a huge put-off considering that it is the best and easiest CI server I have used, but if you are working on a cross-platform tool, it is downright essential that your tests work on all platforms in the same manner so that you can save your devs the headache of maintaining and testing on different OS. That is where it falls short, it doesnt support Windows or doesnt plan to in the near future.
You might not care about programming on Windows, but you do need to care about your users on that platform and make sure that they get the same great experience as others. That is why testing on all platforms are necessary, but sadly using only Travis CI you cant do that. You need to also use something like Appveyor to test on Windows.
Recommendations to others considering the product
Travis CI is not a cross-platform solution, you'll also need some other CI that builds on Windows for cross-platform projects. Appveyor can fit the bill there.
What business problems are you solving with the product? What benefits have you realized?
I am using Travis CI to test my python modules on linux, including some open source projects.
Earlier, it used to be that devs tested all the code on their own machines locally before pushing to Github and make sure all the tests passed. But the problem is, this test results are only available to that particular dev and so others working with him cant be sure of the code quality, specially when the submitter is new-ish. Its much better when everyone can see how that Pull Request performs with existing test cases and be sure that nothing much will be broken if it is merged.
Also, when a issue/bug is reported, it is sometimes hard to replicate for others and the question comes of whether it is because of the configuration of that particular machine, or a weird bug in the project itself. So, putting that potential bug as a test case lets us see the status on the CI and determine if it exists on a standard system.