Try to forget the word ‘install’. It means nothing here.
The question ‘what packages are in my store’ is a coherent one, with a simple answer: ls /nix/store.
The question ‘what packages are referenced by my system profile’ is also a coherent one, with a different answer: nix-store --query --requisites /run/current-system. This will be a subset of the first thing. But don’t think that something in your store but not in your profile (such as, but not limited to, older versions of packages) is equivalent to, for example, a cached package file in Arch. It’s a live copy of the software, and any user can use it via nix-shell or by invoking a binary by its store path. But if not referenced by a retained generation of the configuration, it could also be deleted at any time by garbage collection.
If you use nix-env to maintain a user profile imperatively, or if you use users.users.<name>.packages, or if you use Home Manager, you also may want to know ‘what packages are referenced by my user profile’: nix-store --query --requisites ~/.local/state/nix/profile (if you’re using XDG base directories) or nix-store --query --requisites ~/.nix-profile.
When you set, for example, programs.whatever.enable, what that generally does is add a version of the program to your system profile that has been wrapped to use the specific configuration that you can determine with the other programs.whatever options. This differs from simply adding whatever to environment.systemPackages, which gives you a version of the program that is not specially configured (it will probably use your dotfiles instead). programs.whatever.enable may also set other NixOS configuration options that make whatever function correctly: open firewall ports, add systemd services, set D-Bus policy, etc. In NixOS, all of this is declarative: there are no configuration files left around by old configuration values, outside of the store.
Having a module — a category.something.enable option — is no indicator of additional safety beyond being packaged in Nixpkgs at all. It just indicates that someone cared enough about the experience of using that package to give it some special declarative configuration options.
A Nixpkgs committer could do this (there are 200-odd of us). A mere maintainer could not, without getting approval from a committer (or, theoretically, exploiting some sort of bug in the r-ryantm/nixpkgs-update infrastructure).