One of the challenges programmers face is how to manage complex designs well. For very simple programs the distinction in visibility between public and private program elements is not particularly important. There is little danger in every program element being globally accessible by (and having global access to) every other program element.
For programs of even moderate complexity this free-for-all kind of access is disastrous, and can quickly have fatal side effects, especially if you tend to reuse common variable names...
The modularisation of Pascal programs into units as program subsections with public implementation and private implementation parts is the principal way to manage the visibility of entire chunks of code at the language level. It gives you a way to work with the compiler in restricting access in a clear and consistent way, and allows you to define the scope of variables, types, consts and routines unambiguously.
Later developments in the language extended this visibility restriction concept (as applied to units) to classes. This lets you micro-manage visibility in more detail through the use of visibility specifiers within class declarations (strict private, protected etc.), which further reduces the risk of sections of code stepping on each others' toes.
A further step in this direction is the restriction imposed by {$mode objfpc} which disallows repetition of name use in circumstances allowed by {$mode delphi}. Such features, if you use them, also help to avoid accidental spread of visibility beyond what you intend. In general, the sloppier the coding style, the greater the risk of bugs emerging. The tighter the syntax and the scope of variable use, the easier it is to identify and eliminate bugs.