Back about 1979, we had our own Automated Test bench and I had to make and program fixtures to test 600 ohms telephone-type transformers. The computers were HP 9852A desktop caculators - 64K of ram that had to be shared between the Basic program and running the GPIB card, the RS232 card, the printer, the tape drive and the OS. The end result was that a program was typically a few hundred lines maximum, and variables were A to Z.
To handle all the different transformers, I had to write an interpreter that reads the test instructions from a file on the tape for the particular transformer and run it. The only possible way was to write a RPN interpreter because it is just so simple - is the next item in the file a number? If yes, put it on the stack. If it is a letter, it is a command that can pull numbers off the stack. That essentially is the whole interpreter and only takes about 15 minutes to write. In some cases, a command might put numbers back on the stack for the next command to use. No tokenising, no brackets.
So a test might be:
1 2 I
3 4 O
100 R
1000 F
50 V
49 51 M
which means turn on relays 1 and 2 to connect a winding to the source, turn on relays 3 and 4 to connect the output to the dvm, set the dvm to the 100V AC range, set the source to 1KHz at 50V. Then measure (switch on the source and measure output voltage. If it is between 49V and 51V it passes. Using the RPN order made the programming very simple. The thing is it is also simple for the brain. We often add a huge amount of hidden complexity to things necessarily, particularly now when computing speed and memory is no longer an issue.
If I need to use Trig, I often get the numbers first before I even think about which trig function I need. So I calculate the voltage and phase angle first, and once they are on the stack, I will only start to think about "do I need sin() or cos()"?