Short answer: no. Removing a non-experimental builtin supported since nixpkgs/lib/minver.nix (2.3) breaks expressions. Makes talk of reproducibility kind of moot.
Long answer: functionArgs is an ugly capability that turns nice and simple laws into mere rules of thumb. One rule comes to mind, but there’s probably a lot more: eta expansion isn’t a guaranteed correct refactor: functionArgs (x: f x) is {} and often not equal to functionArgs f.
So while we can’t remove it, we can choose not to use it.
I’ve played with that in Single package fixpoint by roberth · Pull Request #296769 · NixOS/nixpkgs · GitHub, but I ended up using it anyway, because otherwise more boilerplate would be needed. I think the main thing that PR demonstrated wrt functionArgs is that we can have an incremental migration path to a different solution/solutions that solve the flaws of callPackage.
In package.nix files, you’d pick a new solutions like this:
-({ stdenv, fetchurl, zlib }:
+{ mkPackageWithDeps }: mkPackageWithDeps ({ stdenv, fetchurl, zlib }:
I believe one reason is cross compilation splicing, although that seems solvable.
The other one I believe is that doing overrides with pkgs // { ... } will produce many large attrsets, which is quite inefficient.
An alternate representation like feat: persistent lists by ConnorBaker · Pull Request #11767 · NixOS/nix · GitHub or perhaps [WIP] Lazy attribute names by infinisil · Pull Request #4154 · NixOS/nix · GitHub might improve that.