Should there be such a mess in the Menus?

That could be achieved via a review process, i.e. set up rules, and then review new plug-ins and scripts that are submitted according to these rules.

However, this is probably more work than the current admin team can perform.

I have tried to do that in the scripts I create. For example, I created some scripts that generate gradients and registered them in the gradient menu. So many people asked "where is the script? I can't find it!" not expecting to look in the gradient menu.

-Rob A>

My opinion on this subject is that it is the beginning of a very good feature.
For example I don't have the same interpretation of 'Filters ' that GIMP have:
the term has a connotation (for me) of changing the whole image like a camera filter, so perhaps 'Plug-ins' is a more appropriate term, but should I distinguish between plug-ins included with GIMP and those added later by me? Or make them common task oriented, etc.
Hope this illustrate why I consider it a good feature.

There is no absolute place in the 'menu' where a plug-in belongs, it depends on the user, if he/she control where and he/she has that control now. We should not stretch the GIMP developer convention past its usefulness for the developer (sweeping this feature under the rug). The actual diversity (mess) in the menu placement, in the first place, support that view.

So improvement should consist in facilitating, the menu placement, the user's way.
For a graphical desktop solution: probably not in next few years, unless you provide one.
But we can work with what we have now by giving more information.

Starting with the plug-in user:

1- During the adoption phase of a plug-in, there is a GIMP tool under 'Help/Plug-in Browser' to find some info, in particular the menu path for a plug-in if its not known. Also it gives examples of the menu path and there structure (important for the following step 3).
Here I will call the first element (separated by '/') of the menu path the 'root' and the last 'launcher', witch is in relation with the name given by 'Plug-in Browser'.
«For example if you search for 'Plug-in Browser' with that tool you get "<Image>/help/programming" without the launcher and the launcher is "Plug-in Browser".(Edited)»

2- If he/she come from close software (EULA), he/she has to change his/her mode of interaction with open software (GPL) which encourage poking inside (by using mostly text files) without fear of a catastrophe legal or otherwise; here it will be the '*.py' and '*.scm' files of the plug-ins to be adopted. Open them with a text editor (encoding of characters: 'utf8 -sans BOM' was ideal for '*.scm' ).
N.B.: you can also change '*.c' source files but it is more adventurous on Windows.

3- Find toward the end of the open file the one 'register()' function or more than one in some case. In the 'register()' look for the root of the menu path, it's one of
["<Image>", "<Toolbox>", "<Layers>", "<Channels>", "<Vectors>", "<Colormap>", "<Load>", "<Save>", "<Brushes>", "<Gradients>", "<Palettes>", "<Patterns>", "<Buffers>"] for GIMP-2.6, some change for other versions.
Often the root is "<Image>" and it will be used in the rest of the step.
Asterisks will point to the menu path or element of it. There are two main approaches: separation of launcher & menu path (left column) or theirs integration (right column) .
«To change the placement of the menu: modify the strings pointed by the asterisk(s) after the root, respecting the approach of the plug-in.»

launcher & path at the end of          complete path near the beginning of
  a) for '*.py' files with module 'gimpfu':

    register(                                         register(
     ...,                                              ...,
     "2012",                                           "2010",
*   launcher,                                   **   "<Image>/...",
     ...,                                               ...)
*   menu = "<Image>/...")
			  
  with module 'gimpplugin' (example 'minimal-real_1.py'): the name of the function 
   is 'gimp.install_procedure()'.
			  		
  b) for '*.scm' files:

    (script-fu-register "script-name"                (script-fu-register "script-name"
*      launcher                                 **     "<Image>/..."
        ...)                                           ...)
    (script-fu-menu-register "script-name"
*     "<Image>/...")	

4- After changing a couple of menus it becomes a piece of cake and you have transform what at first seems a weakness to a strength. Then you can translate them, change the default parameters in the same 'register()' function etc.
(In my few plug-ins I make no effort to place the menu where «one» user expects it to be. In the long view to place it for her/him is a disservice to that user or unjust for the others. Now we will be able to point them to this comment, if it's understandable!)

5- «If GIMP is running when you change the menus of plug-ins registered in GIMP: you have to restart it if it's a Python one for your changes to take effect and if it's a Tiny Scheme one, you click on 'Filters/Scripts-Fu/Refresh scripts'. After you acquire a little experience you can experiment with changing the root of the menu path. In my experience, complication occurs in the integration approach if the root is '<Image>' (see suggestion 3 for the plug-in developer), don't be discourage by failure, play with it. In the present state of development of GIMP, it's a good thing for the user to know the 'register()' function.»

Ending with the plug-in developer:

Consist of establishing standards to simplify the job of the user. Here are some suggestions.

1- Some plug-ins has a refinement in the blurb which appears when we mouse over the launcher in GIMP.
It gives the file name of the plug-in associate with that launcher.

2- Use of variable for the menu seems not advisable because it complicates the user search for it.

3- While I was using the separation (left column) in my last script because the approach in the right column for "<Image>/..." in Python adds automatically and silently two parameters (image and drawable).
But it is simpler for the user and replacing "<Image>/..." by "<Toolbox>/..." stop this automatism (found that later!).
«After further thought on this, the left column approach is preferable: less complication overall and more flexible (ex.: you can have multiple menu paths for the same 'register()' function).»

4- If there is more than one 'register()' functions in the plug-in file, regroup all the 'register()' at the end of the file.

* «In a Python plug-in the second line should be
'# -*- coding: utf-8 -*-'
to simplify translation, even if the plug-in writer is not interested in translation.»