It's not just the case of "too much to do" but rather the case of very few have considered at all and on the off chance that the checkboard uses one of the colours that the sprites use. The chances are extremely low but is possible. It can also be a visual reason. For people who have a visual impairment, the checkboard might be too distracting making them harder to see the sprites. Using a single colour makes it easier to see the sprites, transparency as well but more on that later.
Also this from experience ripping on Genesis, Master System and Game Boy games, sometimes the sprites don't align for 8x8. You might get a sprite where the first four tiles align, then the next four tiles it might shift one or two pixels towards the left or the right, then the next row might have the same as one or two but might be completely different too or even two tiles have to be aligned. That's not including sprites where you might have a sprite where the middle is 8x8 but then have to vertically align. A lot of it is due to space constraints in the ROM.
It sounds confusing so I'll give an example. This from the cancelled San Francisco Rush on the Game Boy, this is what the sprite looks like when you arrange the tiles and align them to look like how it appears in game:
![[Image: sanfranciscorushgbc-car-example.png]](https://i.postimg.cc/285kZ6ZV/sanfranciscorushgbc-car-example.png)
Then there are systems and computers that don't align to 8x8 at all. ZX Spectrum, Amstrad CPC and Commodore 64 (the 3 8-bit computers that I have been ripping from for the past few years) all have their standards that vary from game to game. A few do indeed fit towards 8x8 but usually just don't. Spectrum and Amstrad along with the Amiga and Atari ST use bitplanes so it goes 8 pixels horizontally, then 16 pixels horizontally and so on but the vertical can be unlimited. A sprite to use the loosest term can be 8x1 or even 8x192 (even 4x192+4x192 if shadow masks are done as a strip). So when it comes to aligning, that's an issue when it comes to animation e.g. Sprite 1 might be 16x31, Sprite 2 could be 24x28 while Sprite 3 possibly be 16x29. It's the case of trying to respect the sprite boundaries but doesn't always work out... C64 is 24x21 in terms of dimension for a sprite but different for the CharSet.
Relating to 8x8... When it comes to aligning and arranging sprites, the graphics program that I use does offer grids to make it easier. For space reasons, I tend to use 4x4 on my sheets but older ones were indeed 8x8. Enough so a person can get the sprite without the mistake of accidentally getting another but compact enough. Ripping from Amstrad is 8x8 since the graphics are doubled in size on the graphics viewer (easier for me due to visual impairment) but shrunk to 4x4 when finished and MAME depends on what size the tiles are listed in the tile viewer e.g. 8x8, 16x16, 32x32, etc.
Many rippers do things their own way, some have the sprites close together and some have some breathing space. Some have sprite boundaries, some don't or both depending on the ripper. Some fully describe while others just have the sprites. They use different tools to do the sheets; some use MSPaint, some use GIMP or Photoshop, some use Sprite Sheeter (usually for something like PC or DS games where a character sprite is either one piece rather than tiles or already arranged when exported), some use GraphicsGale and some use something entirely different for the sheets.
As for the lack of transparency, well... tSR has been going around for a long time, some of the oldest rips don't use PNGs and the early ones that did can be traced back when Firefox and later Chrome had supported PNGs due to Internet Explorer having issues with the format especially broken transparency. Until at least the mid/late 2000s, Internet Explorer was the most used web browser and took until 2011 before it could fully supported PNG but by then a lot of people moved on to alternatives. It was the case of better to be safe than sorry and just stuck. For modern rippers, probably the case of being influenced by the old rips having a background but rips on more modern consoles tend to have transparency e.g. Gamecube/Wii rips. Rarely I do include transparency but usually just the single colour background, been doing that since Day 1 way back in 2006. (On a personal note, usually only have a transparent sheet if I know it's a one and done rip that's not a title screen rip or something. Having a background makes it easier to do updates whether its missing/incorrect palettes, sprites need re-ripping or missing sprites that can happen otherwise would have to strip the transparency and rebuild. Not all the WIP sheets are .gal, some are PNG outright.)
Another reason is in its early days and still applies to an extent today, the main use for the sprites are sprite comics and avatars. Fan games did also exist but at the time, it was more of the Game Maker type. ROM hacks again also existed but they weren't like they are now. That is also why many rips on the site don't have the sprite boundaries because the thought didn't apply when ripping during the 2000s/much of the 2010s. It was and again in some ways still thinking visually rather than technically.
I'll experiment with a few different methods and see what I like. Definitely finding that my checkerboard pattern with sprites directly touching each other is way too visually cluttered and hard to look at, so I think I've got my answer there.