Heavily disagree.
The difference between the CPU and the GPU in practice will be the speed that your code runs. If you have an app where you literally can't run it on a CPU, then there are probably going to be a few older and under-powered GPUs that also will be too slow. In which case, the correct thing for you to do is to do some very minor profiling of your application at runtime and show an error message or make adjustments based on the actual, real-world speed tests running on the real-world hardware sitting in front of the user.
You shouldn't be policing the specific hardware, you should only be checking whether or not the hardware works. Setting up "allowlists" of what hardware we support is contrary to the philosophy and spirit of the web.
Like you mention, there is a scenario where you might like to tell the user why the application is slow, and in that case, the ``GPU.isGPUSupported: boolean`` property seems sufficient to me.
In general though, if your user wants to run your app on underpowered hardware, other than letting them know what the problem is, there is no reason for you not to get the heck out their way and let them do what they want to do.
And it makes sense for the CPU fallback to be the default behavior, because the web is a general application platform for general, amateur programmers, and their defaults should allow them to fall into a pit of success. The idea that "the core library should fail, and the programmer should go out of their way to specify a custom CPU fallback alongside their original code", is just naive. Developers won't do that, the default setting should be the version that works for the most people.
If you have a GPU accelerated application where it's genuinely preferable to just crash the entire application instead of letting it run slower, and if for some reason you can't do profiling instead of blindly assuming that all GPUs will be fast enough to run your application, then you can go out of your way to specify your own fail conditions. But that shouldn't be the default. By default, apps should work.
The way that 90% of programmers will use this library is to have a normal application that has a few expensive operations that benefit from the GPU. For nearly all of those developers, having a default fallback to a slower implementation is the right choice. The 10% of developers that fall into the exception can manually detect slow hardware and code their own response.