MacOS prior to OS X had the same property: literally nothing else could happen at the same time if the user was moving the mouse, which is why you had to take the ball out of the mouse before burning a CD-R on that operating system.
You’re only partially correct about classic macOS: you could definitely hang the OS by holding down the mouse button but this wasn’t a problem for playing music, burning CD-Rs, etc. in normal usage unless you had the cheapest of low-end setups because a small buffer would usually suffice. I worked with a bunch of graphic designers back then and they didn’t get coasters at a significant rate or more than their Windows-using counterparts, and they burned a lot of them since our clients couldn’t get large files over a network connection faster than weeks.
The 8-way PIII Xeon was a Compaq someone tested BeOS on before it went into production. I Remember it being posted on some BeOS news site. There should be another screenshot or two with 25 avi files playing and a crap load of CPU hungry programs running at once. Impressive feat circa 2000. Edit: browse the screenshot directory for the other two. Amazing they survived time, internet, bit rot and my memory: http://birdhouse.org/beos/8way/
The BeOS scheduler prioritized the GUI and media programs so you could load the machine down to 100% and the GUI never stuttered and windows could be smoothly moved, maximized and minimized at 100% CPU. Rather, your programs would stutter. And everything was given a fair chance at CPU time.
Very nice design and the OS was built from the ground up for multimedia and threading for SMP. It was a real nice attempt at building a next generation desktop OS. Had no security even though it had basic POSIX compatibility and a bash shell. Security bits meant nothing.