My take on these:
Server-side code is fun and easy to write, and you can incorporate any feature of SharePoint in order to manipulate it. You can build out vast solutions that touch many different aspects, even outside SharePoint, and bakes it into SharePoint using webparts, timer jobs, event receivers, and the like. It is hard to maintain, and migration to the next version is not guaranteed, and can cause problems for future implementations.
Client-side code is very quick to start and you can see results almost immediately, and this is the preferred method and also supported by O365 and future versions of SharePoint, but 2010's client-side scripting doesn't allow every object or feature to be manipulated, so there are limitations to using 2010 CSOM. SharePoint 2013 has vastly improved the amount of features you can code against using CSOM and JSOM (in anticipation of O365 adoption).