Scientific computing doesn't (only) mean small tight loops doing linear algebra. Scientific applications can be millions of LOC, with all the attendant problems of managing complexity at scale. Polymorphism can well be a useful tool to have in the toolbox. Just because it's not an appropriate tool when writing high-performance kernel code, doesn't mean it's not useful elsewhere.

I quite like having functions which take generic "scalars" (double/float/std::complex<double>/boost multiprecision etc) without me having to worry about the specific type everywhere. Of course, sufficiently far down eventually one has to care about the scalar type, but on a high level, it’s nice to ignore it.

The same goes when building abstractions based on this. Tensor<T> instead of Tensor_double, Tensor_float etc.

And then you have all the typical usecases of polymorphism in the wrappers and callers and executables and whatnot which are also to some degree part of "scientific computing".

One example I often give is the nabla operator from vector calculus that is in one form or another used in any fluid dynamics code. If you define nabla as a function that operates on a Field type, and Scalar and Vector types extend the Field type, then nabla can be coded to return a gradient (Vector) if passed a Scalar, and divergence (Scalar) if passed a Vector. Polymorphism is an elegant way to implement this.