If you can execute code, you could certainly do that, even on 64 bit.

The problem is executing code in the first place. There are other mechanisms in place that can prevent a crash to turn into direct code execution (NX-bit). To circumvent those, you can use Return Oriented Programming (ROP), where you prepare the stack such that you jump into a loaded library or other (completely innocent!) code in memory. The problem then is that you need to know where the code you want to jump to resides in memory, and thats where ASLR comes in. With ASLR, modules are randomly allocated in memory and an attacker can't predict where code he wants to jump to resides at.

(ROP is a pretty fascinating topic in itself. The problem is essentially that you are given a bunch of assembly, and your task is to figure out how to use, combine it into gadgets that emulate generic computing functionality (pop a value from the stack, push a value to the stack, call a function, ..) such that you can build your shellcode from those gadgets)

It does, because the attacker has no means to enumerate. Having the means to enumerate the address space always defeats ASLR (called an info leak). Without that, the attacker has to blindly specify what address they want to write to. Without ASLR, these are static across the same versions of a given app on different systems, so shooting blind isn't a problem. With ASLR, that option is removed.

Most malicious software uses fixed-offsets, so any kind of ASLR makes all this not work. And while it's possible to search the address space, in practice this is actually quite hard, even for 32-bit.

If you guess a wrong address, the process crashes.

With a fork-based server, you don't care much about that. Every time you connect, you get a fresh new process - with the same addresses as the older copies even.

So brute-forcing those is more viable than a browser where you probably won't have more than 1 or 2 attempts per user.