The problem with fish is that it's not POSIX-compliant, and it doesn't try to be (it's a design non-goal), and it's not backwards-compatible with the literally billions of POSIX-compliant scripts and tools already out there.
It doesn't even support `!!` since the maintainers don't seem to like it[0].
The literally billions of POSIX-compliant scripts and tools already out there will run just fine under fish with a hashbang/shebang (a first line that defines what the file executed should be opened with, e.g. `/usr/bin/env sh`) :) . And it's not as if adding a hashbang was painful, not having one is super bad anyway as it leads to uncertainty of whether the script is bash / sh / etc, and can lead to tricky corner cases.
I was a wary zsh user too, until I moved my zsh aliases to scripts with a proper hashbang, then migration to fish was painless, and the benefits are real: I get all the features I expected from my long-tuned zsh, with none of the maintenance/performance pains.
Actually, even for one-time personal scripts I still default to writing (ba)sh, because 1. habit/competence, 2. shellcheck, 3. what you say: examples and resources are everywhere.
Tangentially, upcoming fish will support POSIX && and || (in addition to maybe-even-weirder `; and` / `; or`), and already does if you build from sources now.
So long as you don't need to "source" any of these POSIX-compliant scripts into your environment... A shebang'd script cannot affect the environment of the parent process
Lucky for you. I have really come to love zsh's sh and ksh emulation features for this very reason. I have worked in various work environments where setting up a build environment or a testing environment required sourcing ksh scripts that sourced even more ksh scripts. The majority of the engineers on these teams would "deal with" ksh for this reason but a few of the "geekier" engineers would set up zsh with ksh emulation in order to work in a more usable shell.
It doesn't even support `!!` since the maintainers don't seem to like it[0].