When developers talk about "logs", they're most often referring to plain text files containing information that is meaningless outside the context of the specific code that logged them and has no intended purpose other than troubleshooting that code when something goes wrong.
When developers talk about "internationalization", they most often mean "when the user is a speaker of language X use the string translated to language X instead of the default string".
Given those specific definitions, internationalized logs are almost always a bad idea, because:
Usually, the set of languages that all of your developers can speak fluently is a lot smaller than the set of languages that any of your users might be native speakers in. Thus, if you internationalize logs, it's more likely than not that your developers will not be able to understand them.
Usually, most of your users are not active maintainers of the software they're using. Thus, your non-English-spekaing customers wouldn't be able to understand the logs even if they were internationalized, because most of the log messages will be about specific pieces of code and various implementation details they simply don't and shouldn't ever know about.
Internationalization of a message completely defeats the ability to do text searches for that message, be it developers searching their code or users searching the internet for workarounds.
Internationalization introduces the possibility of translation errors or subtle ambiguities, which are completely unacceptable in the context of software troubleshooting. It's the same problem as logging timestamps without an explicit timezone; you constantly have to waste time figuring out what it actually means.
Of course, if we relax those definitions and assumptions I started with, then there are some valid use cases.
In general, "internationalized logs" are potentially useful when there's an easily-identifiable subset of log messages which are meaningful to the average user, and when "internationalization" means a separate log in the user's language alongside the default language log for the developers.
In practice, if something you could call an "internationalized log" actually is useful, then it'll probably be a feature of the application anyway.
Some kinds of video games do this, particularly ones that behave like board games:
Source: Blood Bowl, screenshot taken from https://www.youtube.com/watch?v=UyQB4kDMZzE
If the "logs" are considered extremely useful or a critical feature, they're more likely to end up in a proper database rather than mere text files. Sales tracking software is a typical example of this:
Whether or not you would call these "logs", the text you see in these images is clearly something we'd want to internationalize if we were maintaining these problems.