Hawk: you're being ignored because what you're saying has no relevance to the tutorial. Whatever design flaws you think it has aren't relevant to teaching how to use it.
In general, menus are static. For menus that are dynamic, they're usually short lived, which means it's appropriate to destroy them and create a new one. This was an efficiency trade-off since the data structure used to store menus is O(1) lookup but O(n) for mid-insertion/deletion.
For the sake of argument, let's consider your world where you can delete items on a menu:
1. Menu broadcasts to all players.
2. Player 1 selects something on the menu.
3. Menu handler deletes item N in response to action #2.
4. Player 2 selects an item that is now keyed to the wrong slot.
5. Menu handler passes the wrong item # and screws up internal bookkeeping in your plugin.
Solving a problem like this is expensive - you need to reshuffle the entire items pool, and then create a temporary data structure on each player which re-maps the old keys to the new ones. All of this takes memory, CPU, and man-hours to test and debug, when all you had to do was start a new menu (which is what you'd do with an old menu anyway, if you look closely).
You can't just say an API is deficient at something without understanding why certain decisions were made. As soon as you add unnecessary complexity, someone will abuse it, and then you're stuck supporting it for backwards compatibility.
You're historically mostly right about newmenus. They were introduced for
www.esportsea.com a while ago with extra features (the menu system there allows menus to timeout). At the same time I wrote the system for CSDM. However I thought it had too much potential to stick around there and merged it into AMX Mod X.
Note that if you're getting hung up on the dynamicness of newmenus, you've missed their entire point. The point of newmenus is abstracting menu termination and pagination, the former which is vital to state-oriented plugins (the kind I am wont to write).