I'm pretty sure compilers always generate RPN code when they encounter formulas, it wouldn't make sense to do it a different way.
This isn't really applicable in this case. The microprocessor in question has a stack architecture - it's essentially a FORTH microprocessor - it's ALU instructions don't take specific operands as the operands are on the data stack. The machine basically has a type of FORTH as it's assembly mnemonics. This is from Koopman's book I linked to earlier and it has the instruction set:
http://users.ece.cmu.edu/~koopman/stack_computers/sec4_5.html.
As for compilers in general, there's no need to generate RPN code if you've got a typical accumulator architecture or a general purpose register architecture. Say you had a typical RISC machine with 31/32 registers, then you would do this:
adi r3, r0, 99 ; r0 contains 0, so r3 <= 99
adi r4, r0, 98 ; r0 contains 0, so r4 <= 98
add r5, r3, r4 ; r5 <= 99+98
and not something equivalent to this which needs a data stack and potentially memory accesses if the stack is not on the chip:
LIT 99
LIT 98
PLUS
[EDIT: I've realised that when you write RPN you're meaning the order of evaluation, i.e. evaluate the operands then perform the operation. When I read RPN I think stack plus zero operand instructions. Actually, it's syntax not semantics. Anyway, if I'm right in my assumption about what your interpretation is, then you're correct as the arithmetic operation will have its operands evaluated before the operation takes place - even in a non-strict functional programming language.]