In principle I broadly agree with your assessment to start with the Sprint Goal and then pull in Product Backlog items to fit that goal, and I certainly agree with the idea that the scope needs to be flexible in order meet the goal, as understanding changes through actually doing the work. I see this as being consistent with the "outcomes over output" principle.

However, after this point I think we disagree. I find that in practice most POs tend load up the team with a hotch-potch of Product Backlog items to full capacity of the Sprint first, and then try to retrofit a lame Sprint Goal on top of it, like "the goal is to complete all the selected backlog items!" (I have been in a team where this goal actually happened.) And indeed the Scrum Guide doesn't make it clear that this is not a valid way to plan a Sprint. If the idea is actually in there that this latter way is NOT the way you're supposed to do things, then it's certainly buried in the detail. Because lots and lots of people seem to be following this method everyday.

One of the things that bothers me about trying to fit a goal within the confines of Scrum is that having such an overarching goal necessarily means that you have to deal with uncertainty about the implementation. And I know we definitely disagree about this point - IMO Scrum deals with uncertainty very poorly. Or to be more precise, you can easily have a situation where you are dealing with uncertainty and change very poorly, and yet still be doing Scrum faithfully.

Upon reflection, I'm happy to have a Sprint Goal and keep it as the prime directive for the team. I just want to rip out the rest of the Sprint rules and replace that all with a simple Kanban board :)