r1k, that works as long as the game doesn't scroll. If it does, the hud will scroll with the rest of the screen in an undesired way. Player walks 1 pixel, the game scrolls and the map (including the HUD) also moves because tiles must be tile aligned. (Well, of course the parts that are sprites wouldn't have to move, but them not moving would look even more odd.)
What's more, tiles are 8x8, but you generally only get one palette per 16x16 pixel region not 8x8. So in this case if one uses the hybrid approach, the HUD should be a cross of 16x16 squares instead of 8x8 squares, or the parts of the map you're using the sprite to show through could potentially be the wrong colors.
The reason games dedicate an entire horizontal bar is that if you lock scrolling for some of the vertical lines, anything that's the to the left or right of the HUD would also be locked.
The grass to the right of the HUD won't scroll because it occupies a horizontal line that's scrolling locked for the HUD.
The reason to use all sprites is they aren't confined to a grid and the scroll value. Not sure if this is a scrolling game or not, but more to think about before decisions are made.
Yes, only 8 sprites can be displayed on a scanline. The most you've got is 7 if you go all sprites, and going a few over is not a big deal. You just have to draw a different set of 8 each frame like this (for the example, the entire HUD is sprites):
(also, it'd be much faster, but webbrowsers don't like fast gifs)
If you go WAY over (to say... 16), only HALF the sprites on that scanline will be visible each frame. But it can be a different half every other frame. This is how quickly Mario in Super Mario Bros. blinks after he gets hit and he's still pretty easy to see during that period.
The scene you've got would be 66 sprites if the trees/HUD were to be all sprites. 51 if the trees aren't. Much like the scanline limit, going over is not necessarily a problem. But more than 64 can't be visible in a single frame.
Apologies if I'm getting annoying!
