It really depends on the font choice and terminal engine. Some terminals (such as VTE, which is the base for most Gnome terminals) renders blocks and boxes without using a font, which makes them perfectly fit the character cell.
With Unicode 16, which is coming out very shortly, there will be 2x4 mosaics (originally identified on Kaypro CP/M machines), which have about half the vertical resolution of the blocks, but twice the time resolution (and allows us to leave Braille for what it was intended for).
After this post came out, Unicode 13 introduced Teletext 2x3 mosaics and their "smoothed" versions (with diagonal lines). Those are also useful for sparklines.
OP discusses the below-the-baseline issue describes it as “annoying but not a deal breaker”.
If this is a deal breaker because you’re aspiring for Edward Tufte levels of visualization purity, OP also offers an alternative that omits below-the-baseline U+2584 and U+2588. The trade off is having fewer unequally sized buckets for the data.
(Could there be font faces without this rendering issue?)
> (Could there be font faces without this rendering issue?)
A comment under OP suggests that the rendering issue is font-dependent. When I view a Unicode sparkline on a test page [1], the rendering issue occurs using Arial, Courier New, Gill Sans, Helvetica, or Times New Roman, but appears to be fixed if I use Georgia, Menlo, or Comic Sans.
