Language-enforced association with methods and functions makes it possible to have full encapsulation in a way that's guaranteed by the language itself. That's not even OO either, just simple object-based code. You even see these same ideas entering FP nowadays, with things like univalent types that enable one to establish equivalent types as "equal", and thus fully interchangeable, no matter how they're structured internally.
Yes, this is true. I'm not arguing that procedural (in the C-style) is fantastic, but it can be scaled decently well, but requires discipline. There are definitely improvements to be had when you start adding other language features that enforce certain things.
The whole problem with "discipline" is that it's hard to write it down and enforce it in a large-scale project. Language-based mechanisms are inherently scalable (at least if properly designed; and arguably e.g. implementation inheritance isn't) and make it much easier to build software "in the large".
How large a team I have certainly worked on large scale projects using procedural languages and I don't recall any problems with the required discipline
This is a natural way to work on procedural code (in an iterative development fashion) to move from prototype/early code to stable, maintainable code. You create global variables, then encapsulate them in a record (perhaps keeping just one record globally), then you move to passing a record around (permitting multiple states to exist side-by-side). Ideally you'd start with passing the record around, but sometimes you just write code to get the concept implemented and refactor from there.