I feel like they're just hitting the limits of a bash+shims based approach. I understand why they've done it, but in the end an implementation in a compiled language will beat that approach most of the time.
There are issues since a shell hook will only work as long as you're, well, using a (supported) shell.
However, it's surprising to hear that they've been focusing on UX. The fact that you have to manually install a plugin, then install a version, and then finally set it, without the tool suggesting any of those steps to you when you forgot one, really makes the tool annoying to use when switching versions a lot.
As a proof of concept I wrote a Fish native version of the function that figures out what local version of a tool to use I do actually use it to show the currently selected version in my shell prompt. The asdf version was unusable in a shell prompt.
It goes through the parent directory structure up until the top level root directory and finds the first .tool-versions file and parses out the version of a specific tool.
The asdf native shim takes ~100 ms in Bash (no idea if it can be optimized, but I assume so). My Fish version takes ~1 ms.
I'm not familiar with the performance characteristics of fish, so I can't really speak to that. I only remember that the developers of asdf themselves had problems with resolver/shim performance and even temporarily implemented only that specific part as a go executable, and projects like asdf-direnv also try to work around the problem.
http://stratus3d.com/blog/2022/08/11/asdf-performance/