Ok, I tested a few more things:

- resetting the project didn't help
- removing and re-installing Boinc didn't help

What I did find out is, that in the repository of Ubuntu 18.04 there is BOINC 7.9.3, while Uuntu 20.04 comes with BOINC 7.16.6. On the Boinc download page 7.16.6 for Linux is marked as development version and "MAY BE UNSTABLE - USE ONLY FOR TESTING". Maybe there is a reason for this and so my latest theory is, that Boinc 7.16.6 is to blame for the problem.

As I wasn't able to get an older download version of Boinc from the official site to run on my machine and do not know how else to install an older Boinc version as a Linux noob, I simply installed Ubuntu 16.04 again on my cruncher and everything works fine.

Hope this information helps somebody in the future.

The setting combination between app_config.xml at one side, and the web site setting - project WU's limitation, cache size - at the other side is not really obvious.

• app_config.xml impacts the concurrent execution of project WUs making possible to avoid that too many WUs of a specific project would be executed concurrently. It is particularly useful (recommended) for MIP1 and ARP1.
  
• Workunit Cache Settings (WCG device profiles) defines how much work the machine shall buffer. The effective number of downloaded WU based on the estimation of the execution time.
  
• Project Limits (WCG device profiles) corresponds to the maximal number of WUs of a specific project a machine can download.

If the Workunit Cache Settings is too small, maybe the machine will not reach the maximal number of WUs being allowed to be downloaded.
If the Project Limits is smaller than the number of concurrent WUs to be computed defined in app_config.xml, the latter limitation will not be reached.
If the limitation defined in app_config.xml is "tighter" than the maximal number of allowed thread, the machine will not be able to reach the maximal possible performance.
It is important to notice that app_config.xml defines computation limitations only but no computation priority. The execution priority remains the same as usual: First In, First Out (FIFO) excepted if boinc considers that the reporting deadline cannot be reached.
Hopefully, the explanation is clear enough.
Cheers,
Yves

I did post this as a bug and ran into a recalcitrant Jord after which I deleted my ID and vowed never to post another bug there again. I don't really care if the issue ever gets resolved and evidently neither does Berkeley. I know it's a client bug and can reproduce at anytime. It has nothing to do with the WCG limit settings on the website. David Anderson made a change to the scheduler and he even admits that the change is not ideal but it was all he was going to do for the time being. Admittedly, if this is what is trying to be pointed out, one could set limits on the projects at the website and that would prevent the client from downloading too much work because it would hit the limits first. However, the website has a maximum of 64 which isn't ideal for those with 128 CPUs (threads). The only other option is NOLIMIT and hence the problem.

I could probably spend some time going through the scheduler code and find where the problem lies like I had to do to prove to them that Selinux was causing an issue with the client recognizing Virtualbox installation. But since they have decided to take a combative attitude (I guess I called their baby ugly) they can wallow in their own muck as far as I'm concerned. Looking at the GitHub site, I think one would need to go back to a 7.14.x release (prior to David Anderson's change) to avoid the problem.