Ah, a table with backgrounds on the cells, that makes sense to me now, sorry I missed that in the initial description—and yes I do still think this is the same thing as in the other thread, it’s just showing up in a different context. What I’m basing that on is the RTF code itself and the mechanics of what are going on. There are distinct formatting methods for highlights as opposed to text backgrounds. Most word processors use the highlight codes for highlights, but for whatever reason Apple’s text engine has always used text backgrounds (hence why we had compatibility issues with highlights in some word processors prior to making it so compile converted background colours to highlights).
So when you set a highlight in Scrivener, TextEdit, DEVONthink, etc., it is actually using a \cb code to set the background, and then terminating that range with a \cb1 code, or “white”. Thus technically speaking whenever you use a highlight, from that point onward within the scope of the text, it will have a literal white background behind it.
The difference is that up until 10.12, the engine has always parsed \cb1 as transparent, or no effective background. Upgrade to 10.12, and suddenly it stops doing that and draws white backgrounds as fully opaque white backgrounds, obscuring any underlying background colour that may be drawn by text editor settings or local background settings on a table cell—which is what I’m pretty sure you’re seeing. (So yes, we agree Cupertino changed stuff without testing all of the consequences of the change.)
Here is my test:

[size=80]A table set up and ready to test, this was reloaded to make sure background cells function properly without highlights.[/size]
After setting that up, I selected the word “five” in cell A2, and press Shift-Cmd-H to highlight the word. At this point here is what we have:

[size=80]Expected look of a table with background filled cells and a highlighted word within them.[/size]
Now, after a reload, I get a very similar result to what you posted (at a much less complicated scale!):

[size=80]In retrospect I should have pulled the cell height out so it would look even closer to what you have, but you can see around the sides of each cell how the effect is only painted behind text, not within the blank areas of the cell.[/size]
Here is the line in the corresponding RTF document for that cell:
\cf0 four \cb4 five\cb1 six\cell
That’s the same formatting codes causing the display glitch in the other thread. \cb4 is the default yellow background colour (i.e. highlight) and \cb1 is white—which is not terminated anywhere, causing it to bleed through multiple cells and ultimate the rest of the document.
Let me know if I’m missing a detail though! We do have this fix already coded, so unless there is a new twist that involves something other than disregarding \cb1 and painting it as 0% opaque again, like 10.11 and every version of Mac OS X prior—I think your drawing problem will be fixed too.