One aspect of client-side solutions is the fact that all your business logic is technically unsecure and open to anyone to look at. A savvy user can simply view-source on the page and see your code! Maybe you don't want to share that specific business process or where you are getting the data from.
Another downside is what happens when you want to execute some long-running process, either one that literally takes a long time to execute or one that requires some external input.
Are you looking to quickly get up to speed on workflows in SharePoint 2013? Later in January I'm presenting a 2-day seminar that's available in person as well as live, online, on workflows with Critical Path Training: Office 365 & SharePoint Deep Dive into Developing Custom Workflows. Interested? Check out the agenda and register here!
In these two cases, including a custom workflow within your application and using the SharePoint 2013 CSOM to communicate with the workflow is just what the doctor ordered! In the first case, the business logic can be expressed in a declarative form with workflow activities or they can call some external custom web service that you've written. In the second case, you can have your workflow start a workflow or communicate with it while the workflow is running.