Indeed! this is a balance between truncating enough so that dada2 does not filter out too many errors, and leaving enough so that the reads overlap enough to merge (min 12 nt overlap in the current release).
As a rule of thumb, I always truncate less: dada2 filters out more reads due to error (presumably a random process), but the reads that remain are merged — so the measure I aim to optimize is the # of reads merged. It is far worse to truncate more, aiming to optimize the number of reads passing filtering, if this means that a larger fraction are removed during merging, because reads lost during merging could bias against taxonomic groups with longer amplicons for the targeted region.
Merging is done after denoising, so does not take phred scores into account at that point. I am not totally sure what alignment algorithm or mismatch threshold is used at that point, you should probably check out the dada2 documentation for details.
dada2 will toss out any reads with > 2 expected errors (adjust this with --p-max-ee if you dare 
) so truncating less will just lead to more reads being thrown out by the filtering step prior to denoising, it will not necessarily lead to issues with merging because the tails have more errors, though that is an element. We are talking about a difference of a few nucleotides here, though: you should still truncate as much as you can to merge with as little as possible, but given the length variation in any amplicon (fortunately for you not too much with 16S) you need to provide enough wiggle room so that you do not cause a taxonomic skew. So I think this recommendation is still consistent with Mohsen et al.'s findings: truncate to remove low-quality tails, but not so much that you skew the taxonomy! This is a much bigger issue with non-16S targets (like ITS, which has very high length variation in bacteria and fungi), but something to be aware of nonetheless.
Again, dada2 will throw out those reads if they are too low quality, so don't worry too much about the effect that those errors will have. Truncating leads to more reads passing the initial quality filter, and more being denoised, but you do indeed need to leave enough sequence to permit paired-end merging.
Yes this is just the minimum alignment length that dada2 uses for deciding whether to "trust" a merge. It is not much, though the subsequent chimera filtering should catch anything too wonky. The benchmarks that various groups have done on dada2 (including my own personal benchmarks using some old mock community data with short-ish read lengths so relying on minimal overlap) convince me that the paired-end merging should be working well: if bad read merging were present, you'd expect all sorts of false-positives but not of the published benchmarks seem to indicate this scenario.
I am not really aware of any good literature on this specific topic using dada2, but agree that if quality is high enough then bigger will (in theory) be better. However, since in practice longer sequences inevitably mean more accumulated error, truncating at a reasonable position is usually best practice. Since 16S has very little length variation in general, it is usually possible to arithmetically estimate a reasonable minimum truncation length.
I hope that helps!