In fact the only case where there is a need for a terminator/separator, is when it would make sense to start a new instruction on the new line. In the example you provided, the + symbol cannot start a statement, so there is no ambiguity.
Maybe not in this particular example, but that would require the programmer to know where and where not to break a statement to the next line. What if you break it before an identifier? It would add a LOT of complexity to the compiler to distinguish between an assignment, procedure call or line continuation.
Language design is all about consistency, or at least it should be, and explicit statement termination was introduced to provide just that - to leave no ambiguous situations as to when a statement ends, apart from the fact that it greatly improves readability, which, as I said earlier is often a big issue with high level languages.
Also think about language extension. Without clarity and consistency, compiler engineers quickly would need to resort to patch work making maintenance/extension more and more difficult over time. Having everything in place consistently leaves little to no room for ambiguity making a compiler so much more simple to maintain and extend. Believe me, I know this from first hand experience.
Also, do not mix the statement separation/termination issue with other building blocks like Pascal's IF statement, which I agree, isn't the best or easiest to understand.
In any case, redesigning FPC to make the statement separator optional simply is NOT doable nor preferable. I can say this with confidence even without having looked one single time at the FPC source code. It would require a complete redesign of the parser which in turn would greatly affect the parts of the compiler that are directly parser-dependent to the extent that the compiler will break completely. Trust me, you'd be better off designing a new language.