Quality trimming: why you don't do quality-trimming prior to assembly? To avoid bias? I already know that I will be asked why I decreased from (the suggested) Q30 to Q8, and why 8 is a good number.

Assemblers are all at least somewhat robust to low quality (they have to be), and most take into account quality scores. So quality-trimming is typically not vital, but of course, it depends on the assembler. And yes, as you surmise, the reason is mainly to avoid bias, but also to avoid data loss in low-coverage areas. If you have very deep, uniform coverage of an isolate and the platform has zero sequence-related quality bias, then absolutely, trimming to Q30 would be great! But that doesn't happen in practice, with Illumina. Rather, the more closely your data approximates this, the more you benefit from aggressive quality-trimming, and vice-versa; since we assemble a lot of extreme-GC organisms, single-cell experiments, and metagenome experiements, we are probably hurt more from aggressive quality-trimming than a lab focused on GC-neutral isolates.

Q8 and Q12 are not special numbers with a theoretical reason for being useful. But based on our empirical tests, that seems be the range where increasing the quality score cutoff stops improving the assembly. Sometime later, the assembly quality will start to decline. But this is very dependent on the data, assembler, genome, and memory available; if you keep running out of memory because of low quality data generating too many spurious kmers, then trimming above Q12 can help. On the other hand, with metagenomes or anything with very low coverage areas that you still want to assemble, trimming beyond Q12 or so starts very obviously decreasing the total genome recovery and contiguity.

Do you suggest error-correcting?

In my testing, error-correction improves the results of most but not all assemblers. Specifically, it improves the results of all assemblers I've tested except for SoapDenovo/Megahit.

I am also asking Trim Galore to keep unpaired reads, that I will merge with the paired reads before assembly. Does it make sense to you?

Not exactly. Feed the assembler both the paired and unpaired reads, but not merged together. Most assemblers have different input arguments for paired and singleton reads.

Can I use bbduk to remove contamination from any organism? Do I do so by adding the organism to the ref parameter? What (and how) BBduk parameters should be set?

BBDuk does kmer-matching and is sufficient for short synthetic contaminants, e.g.:

bbduk.sh in=trimmed.fq out=filtered.fq k=31 ref=/bbmap/resources/sequencing_artifacts.fa.gz,/bbmap/resources/phix174_ill.ref.fa.gz

It is not sufficient for large genomes that may share exact 31-mers with another genome. For that you need to use mapping against a masked reference, as indicated in this thread. A masked version of the human genome is available on my google drive (linked in that thread), and it has in fact been masked with the zebrafish genome, so actual zebrafish reads should not map to it.

I've also been told to remove exact duplicates (since they could be technical duplicates) and I am doing it with BBmap clumpify:

That looks fine, assuming your input reads are interleaved. For paired reads in two files you need to use "in1= in2= out1= out2=". Also, there's not much reason to remove ALL duplicates unless you have a PCR-amplified library (which is not ideal for assembly). For an unamplified library, just remove the optical duplicates:

clumpify.sh in=in.fq out=out.fq qin=33 dedupe subs=0 threads=4 optical dist=40

That restricts duplicate removal to nearby reads. The exact distance depends on the platform; what Illumina platform are you using? Also, this duplicate removal needs to be done BEFORE trimming, and I recommend allowing a couple of mismatches if you are only doing optical duplicate removal because the false-positive rate is incredibly low and allowing zero mismatches will enrich for reads with errors.