The project i'm currently involved requires the development of about 60 portlets. I'm aware that a portlet WAR can include any number, so I'm not sure how many Portlets should I include in a WAR.
The extreme situation would be having only one Portlet by WAR. With that approach I'll gain Portlet independence but the number of deployment artifacts would be very difficult to manage. On the other side if a have only one or two WARS for 60 Portlets the deployment artifacts would be only two but even the minor changes made to one Portlet would imply the re-deployment of many of them.
Is there any best-practice or recommendation for that?
For efficiency you want to bundle many Portlets per WAR. What really matters is the number of EARs, but I'm assuming you are building a separate EAR for each WAR. So the original statement still stands.
As you point out bundling all 60 into one WAR is extreme, and will result in other problems with your deployment and re-testing requirements. I'd recommend packaging your Portlets into groups of logically similar functions. For instance Portlets that collaborate together to provide a single function should be packaged together, as they would tend to be changed and need re-deploy together anyway. Certainly 10 Portlets per WAR is manageable, and having your app split into 6 EARs is also quite a managable number. Remember each EAR has a certain overhead, so just thinking about your development lifecycle, once you have too many EARs the restart times on your dev servers start getting ridiculous. A big EAR doesn't take too much longer to start than a small one. This also holds true for deployment times.
It's all about striking a happy medium between build/deployment flexibility (many EARs) and runtime memory use, deployment and restart times (fewer EARS).