I think having a mechanism for declaring and defining “inputs” across projects systemically, in a pre-defined structure, is actually good, regardless of flakes. In particular I very much sympathize with the view, flake: add Nixpkgs default arguments as input by roberth · Pull Request #160061 · NixOS/nixpkgs · GitHub, that flake inputs turn out to implement a dependency injection system, like callPackage does (if even accidentally). I think this touches a problem of utmost importance: preventing the sprawl of ad hoc vendoring in Nix projects.
In Nixpkgs we mend the vendoring in upstream projects forcing everything to live in the same fixpoint and sandboxing the build. However, when using an out-of-tree Nix project we have no sandboxing mechanism to ensure this project doesn’t spawn extraneous Nixpkgs (e.g. with an extended unfree predicate) instances or pull in more projects we’re not aware of. With flakes, all of that complexity becomes visible in the lock file, and you can also attempt implementing a form of a fixpoint (inputs.${x}.follows) to reduce it. I absolutely do wish to have some form “purity” for this, the “sandboxing” for evaluation.
Ironically, while flakes happen to partially address the issue, they might have been keeping us from designing and adopting a mechanism specifically for the task…