I read this article: Client Side Load Balancing for Web 2.0 Applications. Is that practical to use client-side load balancing? What are the cons?
The article you read, described 'round-robin' DNS load balancing. The benefit to which is that you are relying on the existing DNS infrastructure to balance where requests go... This methodology also has it's downsides...
The first request to your web-sever/app has to occur before this client-side logic can execute I presume? This means that you might as well provide the list of available servers during this request. (This is an argument in favor of the client-side approach)
The most intelligent portion of an application, is the application itself, not the software/hardware infrastructure that agnostically supports it. That is certainly one of the benefits to implementing load balancing anywhere in the application layer. Another benefit is you are theoretically gaining some level of high-availability. Developing an application in this way also means it should be fairly easy to distribute the application to multiple "sites".
Challenges you will face will be all of the typical load balancing challenges / multi-node challenges. If you are using a file-based database, or session mechanism you will need to figure out how you will share them. If you are performing maintenance on one of the servers the client application will need to be smart enough to recognize when it's node is no-longer available and try another. If you use the DNS methodology - your ability to load balance will be directly related to how many IP's you are willing to own. This could complicate the server-side router, reverse proxy, server-ip configuration.
All-in-all I would say client-side balancing is a great approach for most applications. We use a similar approach for desktop applications for High Availability and Load Balancing.
You can also use a mixed-approach. We use a mixed approach for server-discovery by relying partially/secondly on DHCP - that's another story.