DHTML dropdowns need Javascript to work, which is something that cannot be taken for granted. Security aware customers disallow Javascript to prevent pop-ups, dialer software and adware to be installed.
Menus dependent on a mouse and Javascript cannot be made accessible according to the standards. You can create landing pages for each subsection and thus making the navigation independent of scripts and mice, but this means you lose the benefit of an easily maintained navigation you wanted to achieve with the DHTML menu. DHTML menus that don't generate the link data but hide and show existing divs are even worse, as screen reader users or textbrowser users have to skip (or scan through them) without being able to use them
As handy as this way of navigation may appear to be at the first glance (easily maintained via text files, multilanguage in some cases), they have several drawbacks:
Take as an example a DHTML dropdown navigation 3 levels deep. You select the first level, the second, and the third and click on it. The page loads and when you want to go to the next sub-page in level 3, you'll need to repeat the whole process. There is no highlight in the navigation showing me where on level 3 I am right now. I need to add a different mean to the page design to show the user where he is, something the navigation should handle.
A navigation should make it easy for you to navigate through the main sections of a web site and in the subsection the user is in.
The bigger the website is, the more you depend on a search or a sitemap to find your way around the site. You do not need to be able to access every part of the site from every page, this is what application design dictates, not web development. Furthermore, this is the job of a sitemap.
If a user journey requires cross-jumping in between main sections of the navigation, this is an indicator that there is something wrong with the usability or logic of the sitemap itself, nothing technology can fix.
As DHTML is not a specific science and sloppily implemented in loads of browsers, DHTML scripts need to be constantly tested and maintained to cater every new browser while at the same time ensure older browsers support them or degrade gracefully. It is a race, that cannot be easily won.
Search engines cannot follow links that are generated via Javascript. Google amongst others ranks pages by their number of links and connected documents.
A DHTML menu ensures that only the text of the first page gets spidered, all "deeper" data is lost.
The whole aspect about easy maintenance and globalisation of menus can be done in the backend the same way as it is implemented in Javascript in many DHTML menues.
A navigation generated by a server side language can be defined by a database and even allow for online editing. A parameter stored in a session or a cookie can define the language and which elements to be shown or hidden.
By defining the menu HTML once in a template and pulling the different languages from a database or XML files, easy maintenance of the menu system is given and there are no browser/accessibility problems.