Bounds checks are a high-level language construct. A processor executes machine code which has no concept of bounds check. A processor needs to execute every sequence of machine instructions, including those from languages without bounds checks.
Then the other software mitigations listed in the article are not so useful either, because the implementation (and OS, in the case of ASLR) could choose not to use them, and the processor should execute such code too.
Defense works in layers: bounds checking is a programming language technique (although you can typically switch it off in (some) compilers). ASLR is an OS technique, which works even if bonds checks are switched off. IIRC at some point one OS (Debian?) had a bug in the randomness generation for ASLR, and it was easy to circumvent ASLR because of that.
All you need to defeat ASLR is a data exfil so you can dump the process code. A great paper (https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...) from about a decade ago created fully automated ROP against ASLRed processes (though it did rely on the fact that fork() didn't rerandomize on linux at the time).
Though you can have memory pages which are non-executable so I'd say that the processor in fact has this concept.
The whole point of ROP is to get around this. Rather than executing code that you've sprayed on the heap, you jump to gadgets that are already in the binary to construct your program.
Yes, if you see memory as a page-size-grained array, you can see that they are similar concepts.
There are processors with support for bounds checking and hardware memory tagging.