Yeoman has an active community with new generators being created at a rapid pace. Because of the momentum behind the community, you can expect good support and adoption for new tools and frameworks promptly after they come out.
Yeoman generators allow you to quickly set up a new project. Invoked with the scaffolding tool 'yo' they provide a boilerplate & tooling selection. There are over 1000 generators, including generators for ember, angular & backbone, to choose from, the majority of which are community maintained.
Yeoman supports both major build systems - Grunt and Gulp. These build systems will help you automate tasks such as minification & concatenation of files, running tests, deploying and live-updating your webpage among many others.
Yeoman wants webapp development to be more standardized under the "Yeoman workflow" banner. As such it encourages the use of a specific combination of tools - a scaffolding tool (yo), a build tool (grunt, gulp, etc) and a package manager (bower, npm).
Yeoman's scaffolding system allows generators to rely on other generators allowing for better code reuse and standardization between generators that use a common sub-component.
Yeoman doesn't just scaffold your project, but also helps you integrate with your package manager directly, so you can manage your entire project with it.
Combining Yeoman and a backend framework such as Django, Rails or Laravel can create problem because the project structure of Yeoman may not be compatible with that of the backend project. It can be tuned to work but for small projects it can be relatively time consuming.
Developers can also create their own Yeoman generator which are practically plugins with which Yeoman works. Generators are basically Node.js modules and can be created just like any other Node module.
There is also a very detailed and useful guide on how to create a generator on the Yeoman official website.
Everything you need to get a project started is included with CodeKit. Thanks to the professional support, different components of the workflow pipeline are guaranteed to play nicely with each other without you needing to do the research on how to configure them.
More advanced features that may require extra configuration to set up with other workflow wrappers are set up out of the box in CodeKit, like automatic browser updating, linting, and source maps.
CodeKit has a clean and intuitive graphical user interface out of the box. Most other tools in this category run as command line utilities or require unsupported third-party plugins to run with a GUI.
The CodeKit GUI makes it easier to navigate and manage the various components of your project with helpful UIs like dropdowns, and views that provide extra details without having to run a separate command.
CodeKit has live updating built in and will update monitored files across multiple browsers and devices, and refresh CSS without a new page load. Other workflow wrappers have live updating, but they require extra configuration. With CodeKit, everything is set up for you so you can get it up and running in no time at all.
You can navigate your project directory, and use a menu form to set up how it gets compiled without needing to read configuration documentation, or deal with configuration errors. On top of that, file watching and recompilation is built in with no extra configuration needed.
CodeKit provides a clean GUI for Bower that makes it easier to navigate and get information about modules without having to deal with a command line interface.
CodeKit supports live compilation of Less, Sass, Stylus, Jade, Haml, Slim, CoffeeScript, JavaScript and Compass including automatic debugging and minification.
While Lineman is hands off when it comes to what you do on the client side, the workflow and tools used around it are opinionated, which means there's less to set up, the tools picked are fine tuned to work together, and you can get up and running faster without having to decide between dozens of tools. While it means less flexibility with the tools you use, it also means that advanced features are built in and available from the start, and you can focus on building the client side, without worrying about the tools around it.
Although Lineman is fully configurable, it comes with well tuned defaults and a built in scaffold so you can get up and running with advanced features quickly with things like continuous integration and live reloading with less or no configuration.
Lineman prides itself on avoiding assumptions on how things should be done and allows for greater freedom in tool choice. It generates a skeletal app, with no example code. Yet if you choose, you can get templates for Backbone, Ember, Angular and other frameworks.
Lineman tries to minimize the work that the developer has to do but in doing so, it has become a complicated monolith of a software built on top of Grunt tasks. It would be easier and more minimalistic and maintainable for a developer to just create the Gruntfile themselves.
Lineman is designed against code generation, which is a good thing as generated code requires more maintenance to keep library code in sync with the generated code, and is dangerous to use if you don't fully understand what the generated code is doing.
While the tools Lineman uses are opinionated, the build process is not as it uses Grunt, so you can get the benefits of a well tuned workflow while still being able to use whatever compiled languages and build process you want. Also, since Lineman handles the tasks outside of compilation and file transformation for you, you can keep your gruntfile simpler and easier to maintain as it would be dedicated to just the build system, and not other task management.
Because Slush is built around streams and designed to work best with Gulp. It allows you to get the benefits of a streaming build system without having to manage the components yourself.
Because Slush is built on Gulp which puts code before configuration, scaffolding can be done in a simpler more straightforward way. Creating scaffolding through configuration requires more knowledge about the scaffold's specific implementation and remembering documentation, whereas doing it in code is more self explanatory and requires less domain knowledge to get others up to speed.
Because all Slush scaffolds share the commonality of streams, it's easier to combine them through that common interface. With configuration based workflow wrappers, different components may have specific implementations that can cause problems with interoperability. With streams, there's better encapsulation of functionality, making it harder to mess up a scaffold leading to better compatibility.
Slush is still young compared to Yeoman. Although it has quite a few generators made by third parties and it's quite easy to make one yourself. It still has fewer generators than older alternatives.
Slush has a well cataloged collection of scaffolds created for it by the community, providing a large collection of workflows prebuilt for almost any task you might want to perform.
You can view the list of generators here.
FireShell is pretty small compared to Yeoman and it could have very well been a simple generator for Yeoman. This means that you can have the same features by using Yeoman with a generator that does the same things as FireShell but with the added pros that Yeoman brings to the table.
FireShell is particularly opinionated, but it's a great way to get started with best practices if you're not sure where to start. It's a great starting point for new developers and season developers that want to skip the set up, and get straight into writing code.