Is there an advantage to my sequential circuit optimization?
How is this chip supposed to make the snake visible?  The normal approach would be to render the snake onto a bitmap display and also keep a list of either positions or directions, and figure that the snake collides with itself if the bitmap is set on the spot the head is about to reach.  This would avoid any requirement for iterating through the snake segments on every frame if the chip keeps track of both the head and tail positions.

If your goal is a game that outputs a 80x50 grid on video, you need to minimize the number of registers and quantity logic of used by the game (e.g. not using 4000 bits of RAM for the display), and if the maximum snake length is e.g. 512 segments, you could use a 512x2 shift register to keep track of the snake's segments, an 80-bit "universal" shift register (which on each cycle can either be cleared, rotate left, rotate right, or stay put) for rendering the next display line, and an 80-bit shift register to buffer data going out to the display.  So slightly less than 1200 bits of storage total.

An arrangement such as I describe should be workable for NTSC video with about a 2MHz clock.  A collision that occurs between a snake's head and another segment would be detected on the scan line containing the snake's head when the hardware tries to set the line-buffer bit for the appropriate segment.  If one uses a clock that's massively faster than 2MHz one could eliminate the need for some of the extra storage, but since the bulk of the storage would be the two bits per segment for the snake I don't think there's much room for savings.

BTW, if one wants to make things look a little nicer one could use 80x5 shift registers for the line buffers and keep track for each cell of the direction via which it was entered and via exited.  Add in some ROM and an output register and one could animate the snake's body so it would appear to move smoothly.