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, I have recommended FEX #51200 strongly over #22409 and others, but I've since rewritten the core of #51200 as a final improvement on legacy-compatible tools:
The decoders from #51200 and #182013 handle both encodings, and will prune the vertex list and map the face data accordingly. #182013 has more robust type checking, mesh cleanup, and supports some proprietary and nonstandard presentations. It's also significantly faster than #51200 (10-80x binary, 2-3.5x ascii) and #22409 (7-52x binary), though since it's running in m-code, it's still (typically) slower than the built-in tools.
