The holy grail of smashing the stack for fun and profit is to gain control of a pointer so that you can point it at the malicious code to be executed. There has to be an overflow in the program itself that is being exploited. In this example3.c the return can easily be controlled because it is a carefully crafted program. It's a proof of concept of how to overflow a vulnerable buffer to gain control of a pointer, in this case, the return pointer. In a real exploit somehow the malicious program to be run needs to get loaded into executable memory and the instruction pointer has to be pointed at it. The reasons the protections you mentioned cause real-world difficulties:
Find a buffer overflow in the program, can't just write one in there. Say we found one, but there are Stackguard-style canaries between the stack buffers and any other stack frame data, like the return address. Find and perfectly write over the stack canaries when overflowing it so they are unaltered, and hope the return address hasn't been saved somewhere else StackShield style by the program we're trying to get all over, and the stack hasn't been shuffled. Heroically we have a controllable pointer.
We manage to get the malicious program loaded into memory also, where is it? ASLR - Designed to randomize the executable, brk()-managed heap, library images, mmap()-managed heap, user space stack and kernel space stack. That's unfortunate, and tracking libraries and mapping memory is difficult (Unless you're an artist), so we get it on the stack or heap, which is easiest anyway. We get it there, get the pointer on it, but then Non-executable memory pages prevent its execution. Return-to-library exploits, like the one I linked above, were developed because libraries are necessarily executable and present.
