In this model, the real problem here is sudo, which bridges a uid-1000 session to a uid-0 one. If you're administering a security-conscious, multi-user UNIX system, you should not be using sudo from your regular account. Either make a separate account and log in as that, or log in as root directly. (But if you want your Minecraft and your bash to not be able to interact with each other, the traditional approach doesn't have an answer for you.)
Of course, most UNIX deployments today are not multi-user remote-access systems, the way they were 30+ years ago when this policy was set. Most desktop UNIX deployments are effectively single-user systems, and the UNIX isolation model doesn't make much sense there. As a stopgap measure, direct access to another process's memory has been disallowed, but there are other ways for processes that share UID to mess with each other.
However, the most common single-user UNIX systems today are smartphones, either Android (Linux) or iOS (BSD + stuff). Android takes advantage of the UNIX model by assigning each app its own user ID. Angry Birds running as uid 1000 cannot mess with the Chase mobile app running as uid 1001. iOS technically runs all apps with the same uid, but applies extensive kernel-level sandboxing to limit the ways that apps can interact with the rest of the system, which essentially eliminates the rest of the leakiness.
There's a Chromium security document that expands on the traditional "1-part principal" model (identity of the human) and how we need to get to "2-part principals" (identity of the human + identity of the app), which I hope that someone will figure out how to extend to desktop UNIX someday:
https://www.chromium.org/Home/chromium-security/prefer-secur...