If you are literally just installing/updating/removing packages from your system repositories, there is zero reason to ever use dpkg directly, because APT does everything dpkg does (because it actually uses dpkg internally to do it), plus all the stuff that you generally need to do when managing packages that dpkg doesn’t do.
But, APT doesn’t do everything.
The big thing historically that APT did not do was installing DEB packages directly from the package files instead of fetching them from repos (IOW, up until a few years ago you could not apt-get install /some/package/file.deb, you had to use dpkg, or possibly dselect, for that). That limitation is why a lot of older ‘How to install foo on Debian’ type guides often use dpkg instead of APT, and why things like gdebi exist. These days it’s irrelevant though, because you can just pass a package file to APT and it will do the right thing in 99.9% of cases.
The other big thing that often comes up is figuring out which package a given file belongs to or listing the files installed by a package. APT has no options for this (apt-file can technically do it, but that’s not part of APT, is a pain to parse the output of at times, and it only looks at info from the repositories, not the packages themselves, so it does not always work), but dpkg (or, more correctly dpkg-query) provides options to make such lookups.
There are a number of other things APT just doesn’t cover, but just about all of them are only of interest to developers.
