TL;DR: package discovery and usage goes via nixpkgs, therfor putting flakes there should be easy
late to the party, but i really think this is an important topic.
Many people still only use nixpkgs because discovery and usage of packages outside of it is rather hard in comparison: e.g. system.packages = with pkgs; [ pingus ] is WAY simpler than activating flake support, adding the additional import and then adding inputs.pingus.packages.${pkgs.currentSystem}.default to your systemPackages if you even find your flake (as there is no singular place to go to like nixos search for nixpkgs)
For that reason package maintainers also add their package (e.g pingus and prismlaucher) to nixpkgs, because, again, thats how packages are discovered and used even if they have first party flake support.
Their nixpkgs derivation is pretty much a copy of the logic from their flake files, which i think is bad (as there are now multiple sources of truth) and there should be something like pingus = (importFlake "github:pingus/pingus").packages.default possible in nixpkgs.
I also recently added first party nix flake support for rquickshare and found that rquickshare already is in nixpkgs as well (but only wraps a prebuilt binary). Now i want to replace the binary-wrapper in nixpkgs with the actual build process as it is defined in the new flake (not only to support multiple platforms, but because i think thats how source-based package managers like nix are designed to work?). See issue. Should i go the pingus/prismlauncher route and just duplicate my logic over to nixpkgs? (I’d rather not, but I also dont want to leave it as-is)