The game of life is a program that has a simple set of rules and that you can write with a small amount of knowledge.
But. a simple straightforward implementation will be slow. The simpel solution will have 2 for loops, 8 tests per cell (involving more hidden address calculations) + a counter, and 2 or 3 more tests to decide if the new cell state.

On a 24*79 grid you won't really notice much, but it isn't uncommon to find grids into the hundreds. On a 1000x1000 grid, we're talking 1 million cells, needing several hundred CPU cycles to test each cell. Computing a new generation then starts be be noticable.

This is where optimisations kick in. It is quite easy to make more complex "calculate next generation" routines that are considerably faster than the simple approach. Even minor changes can make this several times (yes, times, not percentages) faster.

I use this particular problem as a case in a class on optimisation because it is both fun (especially once you get generation times fast enough that you can start talking about 'smooth animation') and it is an excellent example of how far you can take things (and at what extremes you need to go in code to achieve that).

This is why you find such vast different bits of code to do this, they're all using some form of 'trickery' to make the program go faster, but that comes at added complexity of course.