Lets take two real and random examples, and I'll share what I'd look for:
First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin. All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization that you expect. Quickly scan prepare/package for anything out of place, like downloading more files not defined in "source" or whatever. In this case, "suid sandbox" stuff should make you investigate closer so you understand what that stuff does, many things related to Chrome has things like that. That AUR package also has a brave-bin.sh, so a look through that would make sense. AFAIK, everything checks out, this is literally just downloading the official release from GitHub, and extracts it into the right place, so if you trust the GitHub org/user, you can trust the PKGBUILD. The PKGBUILD also seems to be officially maintained by Brave themselves, so probably already there you can verify the AUR user and be done if you feel lax.
Second example is unofficial package, https://aur.archlinux.org/packages/lmstudio-bin, maintained by noureddinex and created by MadGoat, neither which seem official at a glance. Read through the comments to see if anyone else flagged anything, seems fine so again go read the source of the package and the PKGBUILD. PKGBUILD seems standard, downloads something from "installers.lmstudio.ai" so first thing to check is if that's actually the official website, so use search engine to find official website, copy the URL of the download, verify it's the same. In this case, lmstudio.ai is the real website, but download URL on website ends up being "https://lmstudio.ai/download/latest/linux/x64" in the HTML/DOM, so use "curl -v -L $URL" to see redirects, and then we've confirmed installers.lmstudio.ai is actually what they use for official releases. Read through "prepare" and "package", both seem standard and fine, then look through the rest of the files, all of them seem fine, mostly maintenance scripts for the AUR package itself. Package seems fine as a whole, and we could install it, if we're willing to review it again on upgrades in the future.
This is basically all you have to do. Writing what I did while doing it, made each "review" take maybe 5-10 minutes, and it isn't harder than that, regardless who the user is. You just need to know what to look for, and think how you'd "officially" install it anyways. And if what the PKGBUILD differs from what you'd imagine an "official install" would do, investigate if it makes sense and if not, don't install the package, maybe leave a comment for others in AUR to dive deeper.
Question is if this would be thorough enough for this attack? A package with a slightly more involved build process, maybe some patches because it was made to build on a different distro. Maybe you've already installed (and thoroughly inspected) it before, so you're only updating to a newer version, so you're not as thorough with your review. Or an xz-style backdoor.
Yes, it'd be enough. If a package you're using suddenly adds new 3rd party dependencies, you confirm this is actually needed, and if not, you know something is up. When you install software from random strangers, you have to be vigilant and consider the implications of what you do.
I recall the same situation recently with yt-dlp, as they started to depend on a JS engine for some captcha stuff or related. So when you see that, you need to adjust the mindset of "ah whatever it's probably fine" to "Ok, why are these changes actually here?", and if it's not worth reviewing, you might want to reconsider the approach of installing random binaries from the internet that are flagged as unreviewed.