The OP has translated the interviewers question of "design a readable and maintainable abstraction for a chessboard" into "design the most space-optimized chessboard possible", then wonders why the interviewer doesn't like his solution.
It's the interviewers who are ignorant here, they took a real problem and translated it badly into a toy problem. Then they failed to realize what they did.
The article's author isn't just unaware of them, they've written a petulant, arrogant article demonstrating their own lack of experience and adaptability.
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 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.
This is complicated by the two approaches not being apples-to-apples, however.
If OP wanted to crush the question, they could quickly answer it by saying this is how you could implement using classes and inheritance, now let me explain why OO is a poor solution for this specific problem, and what kind of problem sets OO design is most useful in.
In my case, this is unlikely to yield an OOP solution. I'm even less likely to guess an OOP solution was even expected. And if I fail the interview because this particular company takes OOP for granted, I should fail the interview, and may even be glad I did.
I also think optimization matters, if you can reduce the memory consumption with a simple and elegant solution, why not ?
if you click on a square and there is a piece in that square( there is a bit set in that position in any of the types), get the valid moves and draw them.
if then you click an empty valid space, render the piece moving.etc..
most of the details are usually hidden behind functions. You renderer should not care about the internal representation of your data.
But the interviewers seemed to also miss the ball, making irrelevant and false objections.
Or that the interface to use that code would be harder to understand or maintain?
If not, why mandate the use of OO at all, and if it's OO you want to test, why not pick a better example where it might actually make sense?