Thorbjørn already made the point about compilation - IIRC, Java bytecode is an example of a stack-oriented language. Though this isn't universal. LLVM uses a "Static Single Assignment" thing which certainly has a stack, but in which local variable accesses and expression evaluation use a kind of write-once-then-immutable virtual register model. For mutable data, these things basically hold an immutable pointer.
Anyway, a stack-oriented language can do anything that a LISP-like or Algol-like language can do, computationally speaking. The stack may even have implicit metadata, doing things roughly equivalent to the type inference in ML, for instance - evaluated at compile time, without doing a single run-time push or pop.
The real issue is readability, so the question is which of these do you find more readable...
a * b + c * d
(+ (* a b) (* c d))
a b * c d * +
In principle, the LISP-like prefix thing could be done without parentheses - but would have to use a fixed number of arguments per operator (just like postfix and infix) to do it. I think there's some truth in the old "Lots of Infuriatingly Stupid Parentheses" joke, but that could be avoided while still keeping the operator-comes-first ordering. In other words, you could write a compiler that would accept...
+ * a b * c d
On what is most readable, that is clearly debatable. Infix is more familiar for newbies, but it doesn't take much to get comfortable with any of those forms.
Personally, I'm not even convinced this counts as a paradigm. It's just notation, with little or any semantic impact. For example, all three forms could be handled using a yacc grammar - all three using precisely the same AST form, so that the semantic analysis and code generation doesn't even need to know whether the syntax appears to be "stack oriented".
Oops - I think the basic point is above, but I guess I should explicitly state my answer. Which is basically that IMO there is no particular problem that favours any of those notations. People may favour one or another, but that's a different thing.
What LISP programmers will point out, though, is that metaprogramming works quite will with LISP-like notation. That's more about the parentheses than where the operator appears, though - a variant of Forth that allowed...
(1 2 3 4 +)
... would be just as good. The benefit either way is the simple notation to manipulate using code - the same reason that stack-oriented intermediate languages (bytecodes etc) are popular. Though arguably, manipulating the ordering-agnostic AST form can be done fairly easily too - that's kind of what pattern matching does in Haskell and ML.
EDIT - A clarification...
Using a postfix/stack-based form means just that. For example, it doesn't imply any change of argument order. The following examples can all be equivalent, other than the syntax used to express them...
(< 1 2)
(1 < 2)
(1 2 <)
Note - no need to swap the order of the 1 and 2 just because the operator is postfix
(if (< a b) (handle a_smaller) (handle b_smaller_or_equal))
((a b <) (a_smaller handle) (b_smaller_or_equal handle) if)
((a_smaller handle) (b_smaller_or_equal handle) (a b <) if)
Maybe you'd want to keep the condition near the
if, maybe you wouldn't. Either is fine.
Forth doesn't express an
if either of these ways, but there's no reason why a postfix/stack oriented language can't do so. Forth only allowed integers on its stack (at least originally), but LISP allowing side-effecting expressions to be passed as parameters has nothing to do with being prefix rather than postfix. A postfix language could allow code to be passed as arguments (ie pushed on the stack) too.