Flakes advantages are sometimes more immediately noticeable when not running NixOS, since the unstructured nix expression system used by default in that scenario is not helpful Vs a flake with its structure allowing a standardized way to express many things.
With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.)
This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos.
--
Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems.
Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.
With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.)
This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos.
--
Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems.
Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.