I wouldn't say "don't use transaction", I'd say "use transaction for appropriate cases with smart settings". The docs flowchart you linked to covers some of this.
In addition to the flowchart, if you have a very high cardinality ID with very short durations a transaction ID startswith=something will be faster than a stats by ID because transaction can discard completed IDs from memory while stats has to keep all of them in memory indefinitely.
I also wouldn't say "don't use join", I'd say "use join for appropriate cases". The answers link I posted covers a lot of this.
There are cases where join is the right answer, for example you have a complex search that gets some additional fields from a fast tstats. Trying to merge the two into one OR-stats-search often is counterproductive, and a pattern of search | complex stuff | stats | join [tstats] can be the best solution.
In short, it depends.
... View more