As far as I know (and I might be wrong), there weren't STL reader/writer tools in the base toolbox until R2018b. At least that's what the release notes say.
If you had a file called stlread() which returned a struct, it was probably this:
As to why it's different, that's just what #22409 does. The STL file doesn't represent the face data as indices into a vertex list. It represents each triangle directly as three points in space. The old #22409 file just reads out all the triangles and stores all the vertices. It doesn't prune the list of duplicates. If you look, you'll have exactly 3x as many vertices as faces. That might be part of why it's slower, but it's probably more likely that the new stlread() is using compiled builtins.
It's worth noting that #22409 does not handle ASCII STL files, and despite having an internal function for throwing an error message when an ASCII file is encountered, the code to detect the encoding type and call that function are disabled. In other words, not only will it not correctly detect the encoding, it won't even try to not decode things it's not capable of decoding, resulting in confusing and misleading errors. I keep a copy around as a reference for things like this, but I never actually use it.
As far as pre-R2018b STL I/O goes, these are what I've used. The stlRead() from #51200 handles both encodings, and it will prune the vertex list and map the face data accordingly. It's still slower than R2018b stlread(), but again, that's probably because it's doing everything in m-code.
