It seems like the problem is configureFlags not being overridable, not the shim. This is probably much better dealt with like this:

modified   pkgs/shells/zsh/default.nix
@@ -34,10 +34,8 @@ stdenv.mkDerivation {
     "--enable-multibyte"
     "--with-tcsetpgrp"
     "--enable-pcre"
+    "--enable-zprofile=${placeholder "out"}/etc/zprofile"
   ];
-  preConfigure = ''
-    configureFlagsArray+=(--enable-zprofile=$out/etc/zprofile)
-  '';
 
   # the zsh/zpty module is not available on hydra
   # so skip groups Y Z

As long as we're making --enable-zprofile actually overridable (without the messy preConfigure = null), that kind of obviates the need for a shim, doesn't it? Everything it's doing is the default behavior of zsh except for conditionally sourcing /etc/profile on NixOS only. And it seems like the real problem there is that NixOS users can have shell = pkgs.zsh without also having config.programs.zsh = enable... maybe that's what really needs to be fixed.

My thought is that NixOS-specific stuff should be moved into nixos/ somehow. I don't know whether that's the prevailing opinion but the XXX: think/discuss about this... is from 2011 so it could be time to revisit that conversation.

As long as we're making --enable-zprofile actually overridable (without the messy preConfigure = null), that kind of obviates the need for a shim, doesn't it?

I don't really see how configureFlags being easily overridable has that much to do with the shim. As you note the purpose is making sure zsh have a workable environment in the absence of /etc/zprofile on nixos. While this probably isn't extensively used, it is possible to hit it without misconfiguring the users shell. In general running zsh from a bare bones environment (eg. cron could be such a case I believe).

The shim have been there a long time, which means there's most likely users relying on the behavior. So while I wouldn't be eager to add the functionality today, removing it now, without a replacement, isn't great either.

In the end making configureFlags easily overridable should be uncontroversial and address your main concerns. Removing the shim carries the risk of breaking existing users while the upside is mostly having a shorter/cleaner zsh derivation (the maintenance burden looks trivial to me, not requiring any changes since its introduction in 2011).