>> The moral of the story, at least for me, is that you can occasionally get substantial improvements by understanding what is actually happening under the hood of your application, rather than fundamentally changing your application itself.
Also known as the rule of leaky abstractions, as in all abstractions are leaky.
If you are talking about abstracting, i.e. taking away, similar bits of code into one place in programming, whether it's via polymorphism or refactoring functions, then no, that is not a "leaky abstraction".
I am talking about abstraction as in creating a simplified / unified interface over some complex thing. Abstracting the idea of something from its concrete realizations into its own concept. OSI networking layers, drivers for hardware, modeling real world systems, etc.
If you want to be pedantic instead of snappy, you can change my statement to "all abstraction layers are leaky".
Also known as the rule of leaky abstractions, as in all abstractions are leaky.