My point is not that I'm better at it than some specific library, it's that choosing a library would take more effort than writing some straightforward code.
EDITED TO ADD: In fact getting LAPACK into the build if it's not already there is more of a maintenance imposition than just writing a couple of lines of code for this.
LAPACK is the underlying library behind most linear algebra packages in other languages and furthermore it was just an example. My guess is that you probably don’t have just one line of matrix manipulation ever, in which case using a well established library is a good idea. If not, then sure. Do it yourself. But that’s still more code that you have to maintain now.
That's arguable, because 10 lines of code almost never just stays 10 lines of code, and my point in the first place was more contesting that the dependency is hard to choose, or that there aren't solid proven libraries for this.
1 large, complex dependency (plus the 20 lines of wrapper code to transform your program's internal data to initialise and call the library) almost never just stays as 1 large, complex dependency (plus 20 lines of ...).
If you're truly just doing a 2x2 matrix manipulation once in the codebase, then I concede. I guess I'm blanking on situations where that would be the case though, or where more generalized capabilities wouldn't be useful.
This is why it's important to add a comment to those 10 lines describing the choice, and urging future contributors to reevaluate the situation.
(Of course, one should always reevaluate the situation when making changes to code, but we all need a nudge sometimes when we're afraid of doing the wrong thing.)
The difference between those two things is often blurry from a distance. Business logic is algorithmic too, it's just a question of how specific and complex the algorithm is.
EDITED TO ADD: In fact getting LAPACK into the build if it's not already there is more of a maintenance imposition than just writing a couple of lines of code for this.