Earlier quoted context omitted.
It's not about bloat, it's about accidentally triggering menus when you move your mouse down the page.
Ah! I read the parent's post as sarcastic. But you are right, a little delay can be good.
Good menus are complex. In desktop toolkits, there is a lot of logic to ensure they are accessible and don't behave in annoying ways. For example, a high quality menu will have a certain leeway to trigger into and out of submenus so that you don't accidentally drift into the incorrect submenu should you make an error of a couple of pixels while navigating them. They will have various delays and margins in place so that you are able to move your mouse in straight lines rather than make awkward 90 degree turns.
A good menu system will also be navigable with a keyboard-only and will have access keys to quickly jump to items within it.
Everybody who is reinventing the wheel because they see a menu as a mere "styled list of links that shows on hover" is missing out on the decades of learned UX that desktop systems have gone through. I sigh whenever I read, as I have many times in these comments, about making menus in CSS so that it's accessible to the 0.001% that doesn't use JS, while shutting off the much more real percentage of users that can't use a mouse (users that don't generally have a choice in the matter - unlike those turning JS off).