This is both annoying and understandable. For the dev team, to dive into this performance optimization would mean punting something else from their roadmap. I suspect they weighed their perceived chances of success against the projected cost and reached a certain conclusion which in retrospect seems wrong. The independent developer did not have that "hurdle" as he simply did this at the expense of whatever other fun…
I remember clearly when I first gained a real appreciation for the importance of measuring and considering your actual data. I was trying to optimize a slow project doing some polyhedron dissection on large (~1M polyhedrons) meshes in real-time. As a first attempt I had my sights set on a function which tried to find a certain point on a surface by making an educated guess and then iteratively bumping its estimate in…
Yeah! It's deeply unsatisfying to forego algorithmic optimization but it often isn't necessary.
EG, when I do Advent of Code, I often write a naive algorithm that works correctly on the sample input, and then runs a really long time on the actual problem input. Before I go redo the algorithm, I often run it with PyPy instead of the standard Python, and 80% of the time it terminates quickly enough.
Similarly, whenever I happen to do AoC in C++, my naive algorithms happen to magically be fast enough out of the box so I don't even think about better algorithms. It's unfortunately counter to the intuition that you get from a CS programs that obsess with Big-O notation rather than implementation speed.
Big-O is really important but it seems like the input size where it starts to dominate implementation is much larger than our intuition suggests.
(of course it's also easy to write really bad algos that suck even on small input)