Nice snarky response, not sure it's warranted. There are lots of UI design techniques that work great on desktop that don't work at all on mobile, for various reasons, mostly because there are other interface paradigms that take their place. Dropdown menus are one such paradigm. Typical ways to reorganize this type of design to work on mobile:
1. Show a grid of icons that let you navigate to various parts of the app on a flat hierarchy. Facebook used to do this and now many other apps copied their approach. This nav menu is typically the root view in a navigation hierarchy.
2. Show a tableview where each row shows a different part of the app, you tap to go there. This is also the root view in a nav hierarchy but you can group table rows under headings to essentially get 2-levels showing at once.
Should a dropdown menu creator also make the decision of how to reorganize the dropdowns to work on mobile? No. The decision of how one will display a similar navigational structure on their mobile app is very personal, very rooted to how they currently structure the interface on their mobile app or website.
What do people think is the better approach? Should we provide a responsive, interactive menu that works really well for computer users while providing a simpler, touch friendly menu for mobile users? Or should we provide a single interface that works for both and provides a consistent interface across all devices, but it dumbs down the gloss or functionality on the pc side?
Ideally, either your drop-down menu responds to clicks rather than hovers, in which case it works for both mouse and touch-based devices, or it works with both hover and clicks, with clicks setting the state in a more permanent manner, even when you stop hovering. In both these ideal cases, I believe you'll need javascript in addition to your CSS. I consider hover-only menus, which disappear when you stop hovering, to be a pain to use in any case.
However, I've always disliked the drop down menu. I avoid it at all costs (unless a client really demands it). It seems chaotic to me, and it doesn't give any affordance to being a mechanism that shows more options on hovering.
That said, there are some nice implementations that I've enjoyed using because they can reduce clicks if it is responsive enough. This one could easily fall in to this camp.
When implementing submenus please let me move my cursor somewhat down before moving right. With this implementation you must move your cursor almost perfectly to the right into the submenu.
Mac OS notably lets you move diagonally as long as you are moving more right than down I think. There may be a delay involved too.
When you develop the next cool widget, consider that a large part of the web is now mobile. So that means no hovering, no mouse.
Deal with that.