Foreword: My answer is not really an answer to your specific question but it's a vital, important thing to know that ties into how most people I know use error strings: display the translated error messages to the end-user.
I can't add much more on what Tom already said, the answer is no to your original question, as I'll repeat myself at the end of this answer, a
WP_Error message is a pure string that should hold nothing but simple characters, ready to be used in any system. Putting markup or such in them defeats their purpose, but there's a big thing you probably don't know.
Translation & display of that translation.
Let's face it - error messages are meant to be displayed and most likely translated, depending on your product, but most plugins & themes do this, I can come up with 20+ use cases where error display is crucial. Where do the issues start?
The culprit is Polylang, but it's not its fault, every translation plugin will behave like this, they will never escape their translated strings. On their screens and how they store it, sure, that's the plugins' job, but what you do with the string after the plugin's given it to you - your job.
So, how does it work?
Integrate a string with Polylang, but instead of a normal string, put this in:
Now, when you echo this translated string, wherever, what will happen is, you get a popup:
If you were to just escape it, this would never be an issue. The problem here is that if you gave translate rights to users or there's a hole with the plugin itself somewhere else that allows users to launch a "modify translate string", your site is hacked. In fact, if you have your translation files up and someone inserts any JS and you don't output it correctly and you accept that translation and it goes to the repository, anyone that uses that translation package will have malicious JS on their site, this will probably never happen but just telling you.
Back on track, whenever you output a translated string, it'll give you whatever whoever translated that string did:
echo fav_plugin_output_translated_string( 'string-1' ) // will output whatever matches
which could be malicious, as such, if the plugin doesn't have an in-built escape function, do, depending on where you need that string, but it's 99% of the cases for display within HTML:
echo esc_html( fav_plugin_output_translated_string( 'string-1' ) );
this way, no matter what a malicious user put in, you'll always be safe, or well, as safe as
esc_html is supposed to be.
Remember, when you output any translated strings, never trust them, escape and perhaps leave a way for anyone interacting with your system to turn off that escaping in case they wanna do something with it.
Your theme / plugin is your system, even if it's very extendable, it can never be extended without creating another plugin and what that does - not your job, you did your part and made sure that whenever you output strings or store them for display later on, you correctly escaped them.
There's no way you can control the validator / sanitizers / cleaners of others', but you can control how the escape happens for display.