So in 1980, accountants using ticker tape calculators found suffix syntax less error prone?!

The fundamental point you seen to miss is that Python code (or other languages) is READ a hundred times as often as it is written. Readability counts!

A ticker tape accounting calculator is almost by definition "write only" (yes, technically tapes can be reviewed... But even when they are, it is almost always for individual numbers being correct, not for algebraic form of combinations).

There's a reason that every beginning algebra class throughout the world uses infix notation, and has for 200 years (perhaps with a small exception of Poland in the 1920s). Heck, there's even a reason why when John McCarthy introduced S-expressions in 1958 it was with a promise to flesh out M-expressions as a more readable variant (albeit, that never really happened, Dylan programming notwithstanding).

The main reason that RPN is useful on ticker tape adding machines isn't really the postfix per-se. It's that the most common operation is implicit commutivity of many numbers (more than 2) under addition.  I.e. add all these 20 receipts together without needing 19 "+" signs, but just one at the end.

It doesn't seem to be in the original proposal, but I suppose Python could do that too. But it's a terrible idea to try.

We have the 'sum()' function which covers 98% of the actual advantage of RPN in a bookkeeping context.