CPU utilization is an extremely poor indicator for whether or not your system will feel stuttering or freezing. What makes your system freeze is having more tasks to complete than can be reasonably scheduled in a time frame to as to appear continuous/realtime. Most OS schedulers that I am aware of do not provide special treatment to UI processes and defer to the fact that most modern UI's require many programs to respond in a timely fashion to provide a user interface and do not assign priority unless specially instructed. Most provide (relatively) even priority and have high priority interrupts like Window's ctrl-alt-delete and higher priority to kernel threads.
In Linux actual scenarios for stuttering/freezing are generally represented as a load average >1, and stuttering for me generally starts to happen when I get above 3 and I assure you no Linux system will work without observable stutter when you start getting into the 20+ load average range.
In earnest I have no idea why you tried to use a JavaScript based benchmark to support your point. Even after observing it the number of nonvoluntary ctxt switches barely even registered from baseline, probably from the variety of ways browsers do their own internal threading strategies. I could not see how to change that JavaScript benchmark to make it actually provide an interesting load on my system, so I'll just leave it at that.