Echoing the same thoughts in different words:

“Taint mode” is a semi-automated way of recognizing when the value in some variable came from, well, “outside of this application.”   The real advantage of this feature is that it can also track how other data can become tainted through “an encounter with” tainted data.   This is quite difficult to do through static source-code analysis, but Perl does it very effectively through the use of an attribute of the individual data-values themselves as they pass through the perlguts of the system.   Instead of trying to analyze the program at a source-code level, the interpreter tags the pieces of data, themselves.   There is basically no at-runtime cost in doing it this way, and the results are extremely effective.

Meanwhile, “placeholders” are a feature of the SQL language which allow you to define “input variables,” so to speak, for SQL statements.   In the places where you would ordinarily put a literal value (a number, a string, true or false ...), you instead put a question-mark.   You then prepare() the statement in the usual way.   Each time the statement is executed, values corresponding to each placeholder must also be supplied.   The SQL statement itself does not change.   Not only is this more efficient (because the statement need be prepared only once), it is more secure, since the SQL language-parser never “sees” or considers (as potential SQL text ...) anything that those input variables may contain.

I think that “taint mode” is best thought-of, and best used, as a data integrity feature.   Think of it, if you will, as a “garbage-in” flag, which helps you avoid creating the proverbial “garbage-out.”   Taint mode allows the Perl interpreter, itself, to flag ... and, if you wish, to outright prevent ... a common cause of unreliable or incorrect data.   Of course you don’t want your system to be hit by the Bobby Tables problem, but you also don’t want “tpyos” in your permanent data records, either.