Yes, this can well be an I/O problem. The sort will produce lots of intermediate files and merging them requires (obviously) to access them all more or less in parallel, that is something that HDD drives in general, and external ones in particular are slow at. The only way to improve that with the given setup would be to use fewer sorting threads and more memory per these reduced threads to keep the number of temporary files low.

merging XXX files, using 6 in-memory blocks", but it takes forever.

samtools sort has a -T option to define a temporary directory for these files. Does the laptop has enough free space on the internal disk to at least take these tmp files during the sort? It will automatically be removed once sorting is done. External SSDs are not super expensive these days, even external ones, that could help. Does your institution not provide any sort of computational solutions for this, like server or HPC access? Larger data require some computational power. Imagine you find out that you missed a parameter in the pipeline, do you want to wait 2 weeks again for the re-run?

but things slow down significantly on the sorting

That having said, why do you need it sorted? Is this for standard DE analysis? Tools like featureCounts can make a count matrix directly from aligned unsorted files. In fact, it would even resort the files be name if you gave it coordinate-sorted files. Alternatively, use something like salmon to get counts fast and efficiently. Check whether your analysis really needs sorted files, I have yet not come across a situation where I ever needed sorted RNA-seq bams.

bowtie2 for mapping

Are you aware that bowtie2 is not splice-aware, and do you work with eukaryotes?

Alternatively, use tools that are much lighter in terms of memory, I/O consumption and total processing time for RNA-seq like salmon, unless you really need a genome alignment.

What ATpoint said, but with the following additions

• are you using parallel sorting: samtool sort -@ 8 to run on 8 threads, if your machine has this many ?
• you can install and use glances to check IO usage
• an external ssd, even just 1-2 TB, will make a massive difference (I have seen 250 MB / second sustained IO instead of 50 MB/s with hard disks)
• extra internal drives are likely to be even quicker, but check everything is connected via USB3
• sambamba used to be quicker, but not any more

try this: https://github.com/biod/sambamba

Samtools sort merge step can really thrash the system if it's not performant (eg non-RAID hard-disk).

PRs https://github.com/samtools/samtools/pull/1701 and https://github.com/samtools/samtools/pull/1706 to samtools alleviates this, although it's not yet been released as it just missed 1.16. It reduces the number of temporary files by pre-merging each batch of in-memory BAMs before writing out. It also permits a second stage of merge-and-spill-to-disk again if the number of temporary files gets too large, to avoid thrashing disks. It may still not be as performant as sambamba for sort, but is considerably better than before.

The main way of reducing the sort time though is maximising memory usage. Note the -m option is per thread, but setting is as high as you can will reduce the number of temporary files and speed up the merge step.