When you are dealing with spaghetti code, trying to modify or extract a single object is frustratingly hard.
This kind of code suffers a lot of fragility.
Fragility exists when a small change in one place breaks the project in other places, some that should have nothing to do with your current scope.
When writing clean code you are trying to make the code easy to read, easy to maintain and with little or no bugs.
If you keep the coupling low, when you change a class, your changes are local, and affect only a few lines of code.
On the other hand, in high coupled systems a change affects a lot of classes from your project.
The more places your change affects, the more likely it is to introduce bugs in those places.
Imagine telling your IDE to change the type of a property, and your IDE shows you two hundred classes that will be affected by the change.
That’s not a pleasant and comfortable moment.
In a low coupled environment you will only see one or two places affected.
Spaghetti code also leads to rigidity.
Rigidity happens when the code fights your changes, and even small changes take a lot of time to implement.
If your class is used in the entire project, so it has high coupling with almost all the other classes, it will be hard to change so your system will be rigid.