That repo doesn't encourage anything. It's presenting data that the author found useful for another project they were working on, which presumably did benefit from micro-optimization. You are right that micro-optimization is usually not needed, but the repo and its author never claimed otherwise.

Your assessment of the situation encourages mindless ignoring of optimization. It always depends on the situation. Stuff that is done once in a moon... idc as long as it's reasonably fast. For stuff that's on the hot path you sometimes have to pull up your sleeves and optimize where possible.

At work I just had to implement a heap just because the heap provided by the standard libs wasn't fitting our problem.

Please don't discourage people creating this kind of content. It matters to far more people than you might have in mind.

Most of the time it doesn't except for when it does. Your statement is overreaching and is a micro optimization in and of itself. Valuing to ignore understanding when it is important to optimize in this manner, and when it isn't.

The author's use case is very beneficial to optimize in this manner.

There are several slcie iteration ways in Go. They do have some performance differences, depending on the element types of slices. Please view the example in the end of the article for details: https://go101.org/article/value-copy-cost.html

Yes, but it's always fun to go faster ;)