Because encapsulation prevents people from seeing that code (sort of).Another example of encapsulation is it can enforce devs to adopt better practice. It leads to less undefined behaviour.

As a dev, I should only be modifying/impacting code that I need to be interacting with. I shouldn't be able to accidentally modify X code. If other devs adopt encapsulation, I'm no longer able to accidentally interact with code I shouldn't be able to. This reduces undefined behaviour which is a huge part in producing a stable app.

If my system is allowing for tons of (irrelevant) places to interact with otherwise irrelevant code, I could end up introducing bugs/issues every time I PR code. But if my team adopts encapsulation, it reduces that risk.

In other words, it reduces dependencies. Every dependency you add to a module increases the chance of bugs and increases the complexity of that module. So it's harder to work with a system if there are 10000000 potential dependencies vs only a few. It's cleaner and more clear.

>why would it matter if the user won't be able to see the code itself?

If you can see the code itself, you can derive flaws from it. If it's backend code... now you are subject to a whole host of attacks, because people know the names of your tables. People can utilise specific endpoints and pick flaws in your code.

If it's FE code it's not quite as bad but nonetheless you can still figure out flaws and tailor attacks/exploits based on the code you are looking at