But, as you suggest, per the original writings, the real goal was to better manage upward, and has nothing to do with creating projects.
The alternative is what we gray beards call "have a plan". Well, as much as any one can plan for the unknown.
Agile/Scrum has addressed a significant portion of those concerns by introducing lean processes. This visibility has enabled the business to understands what is happening in the SDLC quickly and can reprioritize and redirect if things are no longer matching expectations.
Where Scrum tends to fail (IMHO) is that it doesn't integrate well with other business units. I think the industry needs to focus on release management (predicting outcomes) as a process to help marketing teams, sales teams, etc... if they need to know what is happening in the next quarter, etc...
Either that or everyone needs to wait until engineering is finished before talking about new features (sounds a bit like the tail wagging the dog)
Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded.
A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.