SPARC and ARM are the only ones I know, and the SPARC is the only one I've worked with in a past life. (Edit: SPARC allowed you to decide the direction of stack growth, it wasn't really fixed. I've heard that ARM does the same. So in some sense, I didn't really answer your question :) ).
Original Arm had an ISA which didn't mandate a stack direction -- the stack pointer register (r13) was not special and it was only the calling convention that decreed that it was the stack pointer. The instruction set's LDM/STM (load/store multiple) insns supported both decrementing and incrementing the base register either before or after the accesses, which meant you could use them to implement an ascending stack if you wanted. However in practice the usual calling convention was "r13 is the stack pointer, and the stack descends". When the Thumb instruction set was added, this convention was baked into some instructions because the 16-bit opcode size didn't allow spending bits on the fully flexible "any base register, any direction, any way" operations the 32-bit Arm encoding used. In the M-profile variant of the architecture, the calling convention is heavily baked into the exception handling model (taking an exception/interrupt pushes a stack frame onto the stack) so the stack must be r13 and grow downwards. In the 64-bit Arm architecture, SP is no longer a general purpose register; I think in theory you could implement an ascending stack, but since the [reg+offset] addressing mode that allows the largest offset value takes an unsigned offset, accessing stack slots via [sp+N] is more natural than the [sp-N] an ascending stack would prefer.
Summary: original Arm gave the software the flexibility to implement an ascending stack, but in practice the stack was always descending, and more recent architecture changes assume this to a greater or lesser extent.
It's not just the direction of the stack: in theory, there are two possible kinds of downwards-growing stacks, a 'full' SP points to the last used entry, whereas an 'empty' SP points to the next free entry. It all depends upon how you 'push' something on to the stack: do you decrease the SP before or after writing the data?
ARM let you choose either approach (making four different stack configurations in total!) - this flexibility is because ARM didn't have any specialised 'push' or 'pop' operations, you read/write to the stack using the normal load/store ops, which have a variety of addressing modes.
AFAIK, PowerPC doesn’t have a stack (or a one-address one that wraps around called the link register); its ABI typically defines one, and that can grow either way, but typically grows down.
Not really having a stack ‘preference’ in the CPU isn’t uncommon for pure RISC architectures, where having an instruction that both jumps and writes a return address to memory is a no-no.
1. HP PA-RISC. "Big RISC" of the mid 80s-90s. Now practically dead.
2. Intel 8051. 8-bit microcontroller which now is found as a core in countless SoCs long after Intel stopped making them. You probably own and use something every day which has an 8051 or 8051-core MCU in it.
The 8051 is a weird enough architecture, especially by modern standards, that having an upward-growing stack is barely even a footnote.
(Examples of its weirdness: it only has one general-purpose register; it has three address spaces, some of which are bank-switched; every register other than the program counter exists in memory; some memory locations are bit-addressable...)
(I'm not saying you're wrong --- I personally know two ;-)