I suspect that what you're trying to achieve is more or less made impossible by how the menu system in windows is designed.
Note that there might be some non-conventional ways around this, however I doubt you'll find such a solution to carry less amount of work than your current strategy of traversing the menu hierarchy.
The thing is, a hierarchy of menus and submenus is actually a tree of regular menus. In MFC you have a tree of CMenu objects and in the win32 C api it's a tree of HMENU handles.
Each menu, regardless if it's a submenu or main menu, have a number of items which by themselves are not objects. I.e. there's no MFC class called CMenuItem and no win32 API handle type called HMENUITEM. If you look at any function dealing with menus, it's always about passing an ID of a menu item. For instance look at CMenu::EnableMenuItem or CMenu::GetDefaultItem.
Now, the real problem is comprised of two facts - Menu items are local to the menu they're located in. If you look at any function in the C API, you always need to specify both menu handle and menu item ID, due to the fact that item IDs can't be resolved unless the framework knows which menu object you're talking about. Hence IDs are not global. In MFC you usually don't need to specify the menu handle, but that's ofcourse because the CMenu object itself wraps the HMENU handle.
The second part of the problem is that there's no natural way of retrieving a menu (CMenu or HMENU) from position. You can get a menu item from position through MenuItemFromPoint, but as you can see you also need the menu handle and the returned ID is only valid in combination with the menu handle you specify. Since you can't get that menu handle any other way than traversing the submenu hierarchy - you're back to square one.
As a final note - the capabilities of Visual C++ menus (CMenu) are always limited to the capabilities of the Win32 C API menu functions, so any functionality not found there is more or less out of reach.