Besides, it's pretty rare for someone to need to write their own sorting algorithm anyway, in production. And if they do but they're so addled they do it from memory and randomly pick bubblesort, hey at least it's fairly easy to be correct.
What I have seen is pretty horrific abuse of Linq (i.e. repeated lookup of `things.Where(t => t.Id == query.Id).First()` as if it was a dictionary) which might stem from the same root cause - not thinking about what your code is actually doing and why it might be inefficient. It doesn't help that there's that there's those oft-quoted Bentley's Rules of Optimization which gives people an excuse to not care :-/
I'm trying to grasp the pedagogical failure that would result in people taking the lesson “implementing bubble sort is a reasonable thing to ever do for non-toy problems”.
(Semi-serious question, as you're quite right that hardly anyone ever needs to write a sort routine by hand these days.)
- Recursion and induction (mergesort, quicksort)
- Lower bounds on running time (O(n log n))
- Data structures (heaps in the context of heapsort, binary search trees in the context of treesort, tries in the context of radix sort, etc.)
- Difference between worst case and average case (quicksort)
- The role of the hidden coefficient in O notation (insertion sort is fast for small n even though its running time is O(n^2))