Yes and no. I think Stallman is right in that it's important to realise the relationships between components are often a bigger and more pernicious source of bugs than the components themselves. It's not a problem when you can pretend the components are actually one single component, which is obviously not possible with service architectures or proprietary code.

I'd expand that to say there's a kind of CAP theorem analogue for code, where if you want it to be sufficiently modular (partition-tolerant) you'll need to either sacrifice availability (before you know if it works you have to check its interaction with every other module) or consistency (you write code assuming the other modules work the way you expect and maybe they don't)

Unfortunately, beyond that core idea this article is just sort of befuddled. It is possible to understand the behaviour of a component without seeing its code (contracts, APIs, specs and tests are all examples of doing this). Further, it's a problem not at all specific to proprietary software. Even if you have access to every line of code ever written you're still not going to be able to understand the million interactions that could exist between all the things currently running on your computer in their various languages, frameworks, architectures and programming styles. And, to the extent that you can, it's probably not a very good use of your time compared with just emailing whoever wrote it and saying "hey, your software's not doing what I think it should do".