Your argument appears to be that "Product" will always be "Product". As others have pointed out, this is not the case because (1) it may print a translation, and (2) it can be altered by filters in your theme or any plugin you have installed.
On the first point: Translator content should not be considered trusted (in my opinion) and so you should ALWAYS (when possible*) escape any localised string. Even if you trust your translators personally, they could innocently enter text that would break your web page if left unescaped.
So to your original question "Is this a correct usage of esc_html_e?"
Yes it is absolutely correct for both your examples.
If you're really worried that
esc_html is overkill (presumably you're concerned about performance) you should at least use PHP's native htmlspecialchars function. I'll probably get lynched for suggesting that, because it's not best practice from a WordPress perspective. (you'll miss out on various other filters and character set checks).
* There is another case worth discussing here:
If the translation is intended to contain HTML, like this example then you will often see authors printing unescaped strings. Ideally untrusted HTML should be sanitized before printing, but even the WordPress core does not do this.
Sanitizing HTML carries a bigger overhead than simply escaping it, which possibly explains why even WordPress has examples of unescaped HTML translations. Here's one in twenty seventeen. Presumably the user-provided search query in
%s has been sanitized, but the translation hasn't. Open up your favourite PO editor and enter a translation like this:
msgid "Search Results for: %s"
msgstr "Oh dear <script>alert(\"HACKED\")</script>"
Voila. Script injected into search results page. Try it. This actually works in twentyseventeen.
We can argue all day whether translator content should be trusted. I'd argue that it isn't. A stray, but perfectly innocent
"<" could break your page.