@chrismurman, humans attempt to create a sense of security through the perception of control. In striving for control, things are often made more difficult than needed. When a cognitive activities, such as creating software, is involved then the complications are often multiplied.
Planning (i.e. releases, road maps, big design up front) is often a manifestation of the desire to feel in control. That's what waterfall has sown for years . . . and continues to do so too often. Though not necessarily incorrect, these added layers are often serve as a comfort blanket which is often never shed, resulting in continued poor project management practices.
Back to the OP. A sense of being finished (never looking back) after completing (perhaps based on acceptance criteria) a Product Backlog item (perhaps a user story) would be a mistake. If such is the practice, then the group simply executing a project plan in Scrum terms is possibly (probably) the reality. This would be directly related to the "observation" in the OP: Sprint Review event as a sign off.
Just because an item generates feedforward with an opportunity to modify the product already created, doesn't mean that it cannot ship. The Sprint and Definition of "Done" provide the small requirements freeze needed to focus on working toward the next opportunity to inspect and adapt. These new desires need to be placed on the Product Backlog and prioritized; repeatedly revisiting the same items can certainly be of questionable value.
The idea of scaling (many teams, many streams of work) is a different topic. Briefly though, it is really helpful to think in terms of good software engineering, i.e. SOLID. Avoid the tightly-coupled monolith through breaking the product (slicing if you will) into smaller products with API items in the appropriate Product Backlogs. The micro-services approach is a step in the good direction, but still often results in big design up front.