I used some of your pages for my thesis so thanks for that :)! It is likely that a scanline rasterizer is more performant, but some of the triangles are really small on a 120x120px display, so just the sorting of up to 1500 triangles for each scanline may have its own drawbacks if many are tiny.
One of the other reasons (aside from needed implementation time) for the current approach is also the hope that future microcontrollers might simply have more cores to throw at the problem so rendering could be parallized a lot faster simply by splitting rendering areas.
Definitely plenty of room for improvement everywhere but time is sadly always a factor, hence why I hope others may be able to help ^^.
What do you mean by "sorting 1500 triangles"? You mean sorting their vertices? I believe you already do that in a couple of places; since you're using a depth buffer, I don't think you need to sort them back-to-front, so I'm not sure what you mean.
True that a 120x120 display is tiny, but that also means that you can get away with two static arrays of 120 elements for the left and right sides of the triangle, no need to do any allocation or use tons of memory.
By scanline rasterizer I assumed a system similar to the original Quake scene rasterizer best described in Michael Abrash's Graphics Programming Black Book.
The method allows saving substantially on any overdraw since fillrate is really the primary bottleneck here.
I did a quick check on your page and it seems the implementation describes a per triangle setup vs the more complicated solution by Carmack and his team? Could still work well for larger triangles, maybe with a check on triangle size to avoid really small ones.
Quake did after all utilize 3 different rasterizers to optimize performance depending on use case.
