I only learned about nix-template recently so correct me if I’m wrong.
In terms of package declaration functionally, it looks like nix-template’s features are more dependent on the selected template and fetcher, I didn’t get any python dependencies when I chose to use black from github instead of pypi. nix-init also has more features in this aspect, e.g. detecting the language/build system so you don’t have to pick the template yourself, dependency inference for rust dependencies, automatically filling in cargoHash and vendorHash, changelogs, and mixing buildPythonApplication or mkDerivation with cargoSetupHook and cargoDeps.
Something nix-template does that nix-init doesn’t is nixpkgs integration - it automatically creates directories in nixpkgs based on the template and tells you how to add the package to top level. This is something I don’t plan to implement for nix-init unless nixpkgs change its directory structure (i.e. RFC140). nix-template also supports creating (plain text) templates without a project, which can be helpful to reduce some boilerplate.
Something fundamentally different is that nix-init is interactive and guesses stuff like the template you want to use and has fzf-like tab completion (with rustyline and skim), and nix-template has support for non-package templates like NixOS modules and flakes.
Some smaller differences are that nix-template has a Qt template which nix-init doesn’t have, and nix-init has a wider support of fetchers