I don’t see anything in that thread that says that running yay is more or less risky than the behavior of the above script.
It talks about the fact that using -Sy to check for updates without running -Su has risk. It also talks about the fact that combining -Sy with -Sa is risky but neither of those situations applies here.
I was referring to this script not checkupdates in general.
There is nothing wrong with checkupdates itself from my perspective.
Running checkupdates only makes sense when you don’t want to update. For example, when you’re waiting for a specific package to have an update, before updating your system, so you periodically check if that update is available. You would not want to check for updates using pacman or yay to refresh your local package database just to check, and then not update. That can get you into a partial update situation.
But this script can also get you in a partial update situation. Suppose you run it, and there are updates available, so the script runs sudo pacman -Syu, but you then choose not to install updates (by pressing N when asked :: Proceed with the installation? [Y/n]). Your local package database is refreshed and any package you install now may result in a partial update situation. So, the whole point of checkupdates, to safely check for updates without refreshing the local package database, is void here. So what’s the point of running it at all, then? This is a serious flaw with the script.
Also, there is really no point in running pacman -Syu before yay since just running yay updates the repo packages first, before updating the AUR packages, and you can safely decline updating the individual AUR packages if your inspection of the PKGBUILD files yields anything suspicious.
So, in my opinion, this script does nothing that just running yay would not do, except it’s a shorter command. But if you really want your update command to be U, you could just alias U=yay 
If official updates require a reboot, I’d reboot first (to keep system consistent) before doing any AUR updates. And after reboot run U again.
Let’s say all in all it seems that if user makes “normal” updates with yay, paru, or pacman, all should be OK. And as we all know, pacman is the only official (=reliable) package manager.
AUR helpers are just that, helpers. Official tools like makepkg can be used with AUR packages, although it is slightly more complicated.
I disagree.
Has nothing to do with the script, if a user makes this kind of error. The same user error can be done with pacman and yay as well.
Has nothing to do with the script. It is a user error.
As said above, if reboot is required after updating official packages, I’d do that first. With only yay it would be a bit more cumbersome.
That wouldn’t even check the internet connection… 
I think most of those points are pretty clearly debatable but I am going to let it go. It is probably just better for us to agree to disagree on this one. 
My intention was not to make less of the work you have done.
I just think this takes a simple process and makes it both less efficient and harder to understand with no practical benefit.
OK so here’s my (very quick) take on a similar thing:
#!/usr/bin/sh
if [ "$(ping -q -c1 archlinux.org >/dev/null)" ]; then
echo "No Internet connection?"
exit
else
repo_updates=$(checkupdates)
aur_updates=$(yay -Qua)
if [ -n "$repo_updates" ] || [ -n "$aur_updates" ]; then
repo_n=$(echo "$repo_updates" | wc -l)
aur_n=$(echo "$aur_updates" | wc -l)
echo "There are $repo_n repo updates and $aur_n AUR updates."
read -p "Update now? [yn] " response
case $response in
[yY]* ) exec yay;;
* ) exit;;
esac
fi
fi
This is probably not the “best code” (and I definitely haven’t tested it extensively) but it provides a way to check for updates before updating with the potential to back out without continuing.
Even if reboot is required after updating the repo packages, there is no harm in updating the AUR packages first, before rebooting.
What’s the point in running checkupdates if you intend to update? yay will let you know which packages are going to get updated.
Yes it would: yay lets you know if your internet connection is down with a perfectly clear “could not resolve host” error message.
It’s slightly better than the OP, but still kinda pointless.
Here is my take, it’s even better:
#!/usr/bin/sh
yay
I use pacman and aurutils, so… 
I use pacman and trizen … 
IMHO there are too many moving parts to always blindly update both with a single command, but this is of course dependent on what aur packages are installed.
I need to conceptually understand what I’m updating before I proceed, I check with these aliases, and make sure I understand the areas of the system that will be affected.
alias cu='checkupdates'
alias tu='trizen -Sua --show-ood --noedit'
I treat repo and aur updates separately too. Once the first is completed successfully I then move onto any aur updates / dependency related rebuilds.
Plenty of them actually, depending on your system and approach to updates…
Let’s say you’re in the middle of a working week with production machine, and you see kernel / xorg / nvidia update…
I wouldn’t rush to it until having some free time, just in case some stupid problems or bugs will come and you still actually need to keep your sanity to not doing that in the middle of work 
And in general, to me at least i like to know exactly what i’m doing before actually doing that 
Well, yes, but you misunderstood me. Here you actually have a situation under which you won’t update (namely, the updates are to kernel, xorg or nvidia), so running checkupdates makes sense. My example above is of the same nature (a situation where I know updates will break my system unless a specific package is also updated, but the update to that specific package is not yet available for some reason).
But if you are going to update no matter what checkupdates returns (the only exception being if there are no updates), which is what this script in the OP does, what’s the point of running checkupdates?
In other words this line:
checkupdates && { sudo pacman -Syu ; return ; }
It’s just a waste of bandwidth.