For server-side scripting, one of the main advantages arises as a result of the client-side disadvantage; browser compatibility. Server side scripts, such as PERL, do not require that the browser has the ability to perform any other functions or have anything enabled to work other than act as a compliant browser that can interpret the mark-up language presented by the server-side script. This ensures that well written server side scripts will work in all browsers, something that the developer cannot be sure of with client-side scripts as the developer does not necessarily know which browser or version is being used (although techniques can be used to establish this, it is not always successful). Server-side scripts are often more complex than those operating on the client side as, by their very nature, they are designed to fulfil many more functional requirements of web sites.
Server-side code execution as a solution to potential virus infections on the client machine greatly depends on the developer and the user protecting themselves. It is well known that infections can spread through the use of scripts embedded into web pages and that many browsers will disable, by default, scripting activities that may carry this threat. Should the developer be unscrupulous (e.g. malware/spyware publisher) it is entirely possible that the ordinary user can be coerced into allowing seemingly innocent scripts to run on the client-side and cause infection however this is outweighed by the potential benefits that scripting provides for the ethical developer. Should client-side scripting be halted then there are also ways that the server-side could be used to push infections at the user and we would lose the performance and usability benefits of web sites, in my opinion, for no good reason.
Deitel, P. & H. (2010) Internet & World Wide Web: How To Program (4th Edition). Pearson Prentice Hall.