This was the original premise of the Smalltalk Model-View-Controller architecture. (Not to be confused with web MVC, which reused the name for something else.) The “Controller” in Model-View-Controller refers to the input device, and a given Model can have multiple independent Views and Controllers. The “Model” is supposed to an object that’s a semantic representation of the underlying thing being manipulated.
One of the visible impacts of MVC is that changes occur in real-time: you modify a value in a dialog, and everything affected by that value instantly updates. This is already common in Mac apps (in contrast to Windows apps, which typically want you to press “ok” or “apply”), so it wouldn’t surprise me if Apple was already using a modern MVC variant. It’s a well-known pattern.
In the Apple documentation for MVC, "controller" refers to a class that sits between the model and view. When data changes in the model, it updates the view; and when the user interacts with the view, it passes events to the model.
Like you said, this separation means you can "drive" the same model through different UIs. That's one of the things I always thought was cool about AppleScript support -- the app exposes a different interface to the same model.
One of the visible impacts of MVC is that changes occur in real-time: you modify a value in a dialog, and everything affected by that value instantly updates. This is already common in Mac apps (in contrast to Windows apps, which typically want you to press “ok” or “apply”), so it wouldn’t surprise me if Apple was already using a modern MVC variant. It’s a well-known pattern.