Can you attach a screen recording illustrating the issue? I don't see the lag you're referring to. For assistance, please read https://community.kde.org/Get_Involved/Bug_Reporting#Screenshots_and_screen_recordings

Created attachment 111433 [details]
lag example

obviously lag is a subjective thing tempered by your expectation, mine is set here by the application menu and it's responsveness, in comparison of the two the global menu is clearly slower and less responsive, not the end of the world but would be nice if they were on par, or at least closer

Ah, I see what you mean now.

in relation to this menu, is there any way a shortcut key could be made to open it? I put this request in a separate feature request though probably not very clearly...

Would you say the context menus in dolphin have an "excessively long delay"

There's two things at play here:

1) appmenu potentially has some delay as it has two query the relevant app on open. My timing normally has that in the order of <1ms. So I'd be surprised.

2) QMenu's (that this doing this rendering) has sloppy menu support. This makes it easier to select an item from a submenu whilst moving the mouse diagonally without activating another menu. Something kicker doesn't share the same settings for as it's a different menu implementation.

The latter is technically changable in the breeze theme; see relevant enums in https://doc.qt.io/qt-5/qstyle.html#StyleHint-enum mostly QStyle::SH_Menu_SubMenuPopupDelay but also QStyle::SH_Menu_SubMenuSloppyCloseTimeout. We can tweak them, but those delays are there for a reason.

I see you're  point, accidentally opening sub-menus, though if you look at it another way, which is my experience via launcher menu, it's fine to have them open sequentially immediately and very responsively, until you reach your desired sub-menu and if you drift off that somehow, it is as immediately corrected, by virtue of it being immediately responsive, as the mistake was made initially, by realigning to your desired sub-menu; if this were  a recurrent problem it may be more to do with the geometry of the menu being easy to drift off of; the alternative solution of a delay means the compromise of a delay in opening the desired sub-menu choice and so invites an arguably unnecessary click to open it, if you are impatient like myself, and can't wait for the hover to open it, which isn't a bad way of doing things, but less economical and fluid. personally, without fluidity and a hotkey to open and display the menu prior to my cursor reaching the sub-menus, I'd not use the global menu, when I can have them ever present to directly access on the traditional menu bar, the only purpose of the global menu is aesthetic otherwise and to provide slightly more screen space but not for a compromise in workflow

Can you confirm it's the same with dolphin context menus so I can recategorise this more appropriately?

Yes it's same in doplhin menu system.