The simple answer
So suppose you run this code through (pdf)LaTeX:
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\begin{document}
`` (“) '' (”) ,, („) -- (–) --- (—) !` (¡) ?` (¿) << («) >> (»)
\textquotedblleft \textquotedblright \textendash \textemdash \textexclamdown \textquestiondown \guillemotleft \guillemotright
\end{document}
fontenc will load t1enc.def which includes the following definitions:
\DeclareTextSymbol{\textquotedblleft}{T1}{16}
\DeclareTextSymbol{\textquotedblright}{T1}{17}
\DeclareTextSymbol{\textendash}{T1}{21}
\DeclareTextSymbol{\textemdash}{T1}{22}
\DeclareTextSymbol{\textexclamdown}{T1}{189}
\DeclareTextSymbol{\textquestiondown}{T1}{190}
\DeclareTextSymbol{\guillemotleft}{T1}{19}
\DeclareTextSymbol{\guillemotright}{T1}{20}
As I understand it, this means that you will get the correct character even if the font has not been set up to support standard T1 ligatures. Provided, that is, the correct glyph is in the correct slot. So if the font for some reason deviates from the standard set by T1 in a different way - it puts ¡ in the wrong slot but sets the standard ligature up to point to that (wrong) slot - then you will get the wrong character whereas the ligature would have got you the right one.
Neither of these is especially likely because any font you are using through (pdf)LaTeX has been set up for TeX. So only if somebody has introduced an error will things go wrong. In the first place, mostly people automate much of the work involved and the tools are generally reliable. In the second, something like this would get reported as a bug and (hopefully) fixed.
The encodings are standardised and the font packages are generally reliable. So both the commands and the ligatures are reliable. Neither is guaranteed but I don't think one is any more subject to error than the other.
Complications
There are sometimes reasons to 'tweak' or customise a font encoding such as T1. For example, I might adjust the encoding for a particular font in order to accommodate additional characters or ligatures. Now things get complicated. In order to do this, I must use slots assigned by T1 to something else. It is conceivable that somebody might use a slot normally used for one of the characters above for something else and then delete the ligaturing commands pointing to that slot. The only good reason to do that would be if the font didn't provide the glyph and it could not be constructed from other glyphs in the font. In that case, if you could use the slot, you might. Now you might think that in such a case, you should also redefine the relevant \text... command. However, if you do that, you'll overwrite the command for other T1 encoded fonts. So you shouldn't. You'd just have to flag it in the documentation. But notice that in this case things are going to go wrong anyway - since the font doesn't supply the glyph, both the ligature and the command are guaranteed to give the wrong output. There's nothing you can do. At least, there's nothing terribly straightforward you can do, and nothing at all satisfactory.
But almost all fonts supply the particular characters in question so this is largely hypothetical. The exceptions would be specialist fonts such as decorative fonts where you might have a very restricted character set. If you are using those fonts, though, you likely know about it.
In general, getting the expected output is complex. It depends on the active encoding and the font. In the case of (pdf)LaTeX, it depends on the .tfm file and, perhaps, the .vf in addition to the .pfb or truetype font itself. Depending on the font package, there will be multiple encodings involved. For example, you might use a completely different encoding to point to slots in the original font while using T1 or a customised T1 to define the font encoding at the end-user level. Virtual fonts can combine characters from different fonts, specify 'fake' glyphs by telling TeX how to construct them from other glyphs, and so on. If a font does not supply the ff ligature, for example (not uncommon for expert fonts providing small-caps), you can use a virtual font containing instructions for constructing the ff ligature from the f glyph.
When people point out the difference between input and output encoding, they are glossing over the true complexity involved. In many cases, there are additional encodings involved as well.
textcompwhereas their ligature equivalents do not. I am not sure what you mean by whether it is 'more of an encoding or a font thing'. It is both, in a way. But the ligatures for (pdf)TeX are in the.tfmfiles. When you create these, you set them up to do the expected thing. You can make them do other things if you choose. E.g. you can makesat word-end typeset a swash s via a ligature.pdflatex. (I think that's normally assumed unless clarified to the contrary. But it's not surprising that the answer heavily depends on the choice of engine.) As always, information about other members of the TeX-family is welcome.