I think it's the latter, although perhaps one should blame how we supply our info. By the time you're selecting that option, I think you're just running jupyter-nbconvert, which just works with the ipynb file; there's no kernel/state to query otherwise.
For instance, "show(x^2)" leads to this json fragment:
"outputs": [
{
"data": {
"text/html": [
"<html><script type=\"math/tex; mode=display\">\\newcommand{\\Bold}[1]{\\mathbf{#1}}x^{2}</script></html>"
],
"text/plain": [
"x^2"
]
},
"metadata": {},
"output_type": "display_data"
}
],
"source": [
"show(x^2)"
]
As you can see, the output is available in two representations: text/plain and text/html. It doesn't surprise me that ipynb-to-latex conversion doesn't try to untangle HTML.
The %%latex special inserts a "text/latex" mimetype entry. This does get rendered properly in html in my browser and it makes export->PDF produce an error because "pandoc" is not installed. So this seems to be a route that may make cells more latex-friendly. I don't know what the protocol is exactly, but I suspect our kernel can respond with various mimetypes when reporting back output. Using "text/latex" rather than "text/html" might lead to better results sometimes?