For example, to install a package with pacman one would use:
pacman -S <package>
While somebody using dnf would type:
dnf install <package>
While pacman uses the -S option, dnf uses the subcommand install.
Some other examples are nmcli and tar, with nmcli connection up <connection> (uses subcommands) and tar -xzvf <file> (uses options).
What are the pros and cons of each, or is it just personal preference?
A more technical term for what you call a "word" is "subcommand". It is quite common to design a command line interface as a command with a number of subcommands each with its own set of options. Sometimes subcommands have their own subcommands. git is one such example:
git remote add -f -t "$BRANCH_NAME" "$REMOTE_NAME" "git://example.com/repo"
One reason to split a CLI into subcommands is to emphasize that it can do several different related things. dnf can install pacakges, remove packages, upgrade packages, search for packages, show info about a package etc. All quite different actions. Many of those actions have extra knobs you can tweak and choices you can make via options.
Another reason to use subcommands is that a subcommand provides a namespace for options: --all in dnf list --all means a completely different thing from --all in dnf search --all
Yet another reason to split a big CLI into subcommands is documentation. Imagine if git did not have subcommands. The entire git manual would be one looooooooong page detailing every option that git has and the relationships between them. Also: run git commit --help - you'll see a help page specific to the commit subcommand. Also: install tldr and run tldr git commit - you'll get a cheat sheet that is specific to the commit subcommand.
One more consideration is that you should not use subcommands if you want to allow the modes of operation they enable to be combined. You can specify multiple options in a single command invocation, but you can only specify one subcommand.
apt-get install (- to remove a package, _ to purge it, etc.).