The idea of the plugins is to let people know that an update is available without having to check manually. Maybe restrict it to auto-checking once per day?

The design of these two plugins allows the control panel to be loaded while asynchronously checking the update status of their respective groups. The plugins will use the cache settings of the update checks to decide whether an update server needs to be pinged (which results in extra HTTP server-to-server calls) or if what is in the cache can be used. Changing this to a synchronous process is a step backwards and ends up being render blocking to view the control panel, and depending on the site and last admin activity could result in a rather lengthy delay (imagine a site where 40 update servers must be pinged).

If you feel these plugins are really excessive as far as resource use goes, disable them and you will no longer have update notifications on your control panel (meaning you will have to manually check the relevant update pages).

I'm closing this issue as it is working as intended (actually it's a feature, not a bug).
Also as Michael already wrote, if you don't like the behavior you can turn it off by disabling the plugins.

This is nonsense. EVERY TIME you click on "Control Panel" the back-end checks for updates to Joomla, Extensions etc. That is not necessary to do more than one time when the back-end is accessed, not EVERY TIME the "Control Panel" link has been clicked. This uses up system resources, bandwidth plus data time if using a mobile device. That ISN'T A FEATURE - IT IS A FLAW. Check it once ... but not EACH TIME. If you are doing extensive back-end administration and need to go back to the "Control Panel" dozens of times in a day, it should not be necessary to do a "check on updates" routine each time.

Every time you land on the control panel there are two extra AJAX calls for those plugins to get their stats. What happens under the hood is first the current update cache is checked to see if update data is cached then determine if that cache has expired. If it doesn't exist or is expired, then for every entry that needs to be checked, the update server for that resource is called and the update data stored with a fresh cache timestamp. If everything is cached, then you're getting a rather quick response from the server; if something has an expired cache it takes a little longer because now that process has to wait for however many update servers need to be called to be processed.

Turning this into a static check that only executes once per day is a flawed implementation. This assumes that all vendors publish once per day at or near the same timeframe, and does not account for actions taken by the user while logged into the site (if you update extensions, that cache should invalidate, so your next visit to the control panel should reflect updated data after updating extensions otherwise the checks are wrong). The default cache timeframe for an update is 6 hours, if you first log into a site at 8:30 and a vendor publishes an update for one of your extensions at 14:00, then when that extension's update cache expires around 14:30 you'll see the update notification; by your logic this notification would not show up until after 8:30 the next day.

Again, if you feel these checks are too resource intensive, you are free to disable the plugins.

I have done a PR that it works like @mbabker says. Please test it #24217