I think the author's approach is data-centric rather than object-centric.

His methods would be easy to persist: write the longs to a file. Easy to render: based on bit positions, draw a piece. Easy to understand. I looked at it and immediately knew what was happening (which almost never happens when I have to look at a massive class hierarchy). History would be trivial with his approach: since it's space-efficient, you could literally store the bit-space for each previous board configuration or if you wanted to optimize more, you could store a simple sequence of moves.

I highly disagree. Implementing an AI requires being able to work effectively in chess notation. Either you can choose long algebraic notation, which is pure squares (which can be encoded/decoded into a move type) or short algebraic notation, which requires knowing piece types (which is an AND between a bit representing the square and piece type bitboards) and being able to differentiate between multiple attacks to a square (which is an AND between the move square and attacks by other pieces of the same type).

This is complicated by the two approaches not being apples-to-apples, however.

why? the bitBoard describes the full game state, your renderer can use the data to draw the board for seamless decoupling.

I don't see how the history would make any difference?

bitshifting might be a bit hard for newer programmers but it's abstracted under global functions.