You can't hope to exploit an ASLR'd executable without first understanding how to exploit a non-ASLR'd executable. If you want to exploit modern systems, you need to peel back those mitigations one by one (if you're lucky you can jump over multiple layers at once, but not always).
Further, just because mitigations exist, it doesn't mean they're widely deployed. As a recent and prominent example, the Nintendo Switch bootrom was pwned through a classic stack-smash with shellcode-on-stack in ~2018 (or 2017, for those in-the-know).
That said, there are more modern resources available these days, I'm also a fan of https://github.com/RPISEC/MBE, which kinda speedruns you up to the state-of-the-art (although it too is getting kinda old at this point - but things haven't changed that radically since 2015)
Many of these will simply not compile without explicitly disabling a compiler warning, and except in rare cases, the rop challenges are impossible.
I'm just commenting on what a huge win I feel it is for the software industry that in the past 15 years these went from "copy the binary to your local machine and it works exactly the same, gcc doesn't even warn about this" to "it doesn't realistically have this vulnerability when run on your machine, nor will it build from source on your machine."
edit: wikipedia is claiming linux has had ASLR since 2005 so maybe I'm wrong.