I've worked on SharePoint Portal Server projects and roll-outs where the client/business has decided to develop and use "hover" or "fly-out" style menu navigation for navigating through SPS Areas. It is a fact that in each of these cases I have witnessed the following:
- The number of Areas in the system from the time the menu was developed to the time leading up to the roll-out of the system has exponentially increased (I've seen up to about 175).
- The menus use the SPS object model and make recursive calls to obtain collections of SPS Areas and their children.
- Performance of the menus becomes very slow leading up to the target launch date.
- There is an urgent scramble at the last minute to fix the performance problem.
What's even worse is that I've seen clients implement custom menus that don't have all of the features they want, so they rearrange their site taxonomy and structure just work around their menu's limitations. Shouldn't it be the other way around? Taxonomy in SharePoint is crucial for a successful roll-out, in my opinion.
Generally, I hate fly-out menus. If you really need that many links on a page for a user, then you should think about the design of your site and navigation strategy again. Out of the box, the SharePoint products have very simple, effective and high-performing navigation. My adivce is not to touch it. It can be customized enough through control properties and CSS such that it should be able to fit 90% or all of a business's needs. That other 10% can probably be ignored.
Please, don't mess with your own custom navigation in SharePoint unless you know what you're doing. The SPS object model is not efficient enough to meet your needs on its own, and you'll need to implement some caching or some other creative way to obtain your menu data.