To a large extent it really doesn't matter what a specific implementation detail looks like.
Does this factor in making sure a particular class "should know" about particular objects to get the job done and "should not know" about other particular objects even to get the job done?
Does the implementation not matter because "design always change so it should be a worrying issue to over think the design"?
My eyebrow raised when I read this statement.
You still need to be smart about it, but assuming the design is stable and you are skilled enough to right low-defect code, I still feel the specific implementation details aren't that important.
In my experience most code is only written once, and it is pretty good. There are usually only two real troublesome spots. The first troublesome spot is where design changes and code must be modified to reflect it. Fortunately good designs keep this to a minimum. The second troublesome spot is defective code; either through bugs or performance problems or some other defect. Usually this code is clustered around confusing areas of design or boundary conditions.
As ad hoc numbers I'd say about 60% of all code falls into the single use bucket. It works properly, it does the job listed in the function name, it is easy enough to read. Nobody (including me) will ever revisit the code. About 20% of the code will be reviewed periodically when people are hunting down issues or design changes but not really modifying, and the remaining 20% will actually be modified for various reasons in the future.
In a code review I might make a comment that something looks a little clunky, but if I can see what it is doing and the results are valid, I'm usually fine with mildly ugly code.