I'll express a somewhat dissenting opinion to the rest of the provided until now answers: yes, UTF-8 (or, rather, more generally Unicode at large) is partially and indirectly responsible for the bloat in the required CPU resources. But its contribution is just a drop in the ocean, small enough for most people to say "no, it isn't". Rather, it's the mechanism by which it adds overhead is what's responsible for a large (but not dominant) part of that extra processing cost.
If you want to pin specifically basic processing of the multi-byte sequences in Unicode as the culprit for increased processing resources usage, you'll have to look at 20-25 years ago instead of merely 10-15. 10-15 years ago the various Unicode encodings were already common place - mind you, that was Windows XP era, which is Unicode-native. And as others have already pointed out, UTF-8 (or any other Unicode encoding) adds little to no processing overhead, especially compared to the existing encoding schemes for CJK languages.
What wasn't quite as common ten to fifteen years ago is the use of encryption everywhere, video, animation, UI effects, and a much stronger focus on security than ever before.
- Until Windows Vista desktop GUI visual effects were mostly limited to things like showing the whole window content while it's being moved/resized, shadow under mouse pointer, etc. Since Windows Vista - shadows under Windows, smooth scaling animations, and other effects became much more common, and they all need CPU and GPU processing time.
- If you don't have sufficiently new CPU with AES-NI or similar hardware implementation of encryption, modern-day trends for encrypting everything will impact your CPU usage as well. E.g., the difference between system with and without full disk encryption on something like Core 2 Duo or a first-generation Core i7 is noticeable even without any benchmarks, but do the same on second-generation Core i7 with AES-NI and performance difference is nigh-imperceptible. Same applies to various TLS-encrypted connections (e.g., HTTPS), where you typically have AES-encrypted session, except for both end points to agree on symmetric key they must first use un-accelerated asymmetric encryption for initial key exchange. Combine that with the fact that modern websites usually pull resources from multiple hosts and thus need multiple HTTPS connections...
- Nowadays it's very common to use video where in the past an animated GIF would be used. Many modern websites show videos in a loop at the top of their main pages, and sometimes even multiple videos spread throughout the page. More animations, more visual effects - it all adds up very fast.
Finally, to your point about more sluggish behavior of modern XML parsers - XSLT is Turing-complete; C++ templates are Turing-complete; PostScript is Turing-complete; C++ exception stack unwinding is Turing-complete; ELF metadata is Turing-complete; MMU (memory management unit) page faults are Turing-complete; return-into-libc is Turing-complete enough to use it as attack vector; CSS is (almost) Turing-complete; SVG (which is XML-based) is Turing-complete; MS PowerPoint animations are Turing-complete; Speculative execution in modern CPUs is Turing complete (Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi et al, 2019-02-14), providing essentially a "shadow computer" of sorts for executing side-channel attacks. TrueType fonts are Turing-complete. And last but not the least, Unicode itself is Turing-complete as well, with its bidirectional algorithms being complex enough to support tag system and implement logical gates.
In general, the more "universal" some system is intended to be, the more likely it is to end up being Turing-complete. If we still used language-specific character encodings we wouldn't need bidirectional algorithms and thus there would be fewer opportunities for Turing-completeness. The problem with all of those unexpected and surprising examples of Turing completeness is that they all have security implications - once an attacker gains sufficient control over data being fed into those Turing-complete systems they can compromise your system and do anything they want with it. So mitigations pile up, checks for input sanitation, barriers that make optimizations like speculative execution less effective, etc. They all have performance impact, slowing our systems down. Specifically Unicode, and especially UTF-8 cause only a small fraction of all the security vulnerabilities out there that need mitigation, but they certainly do their part.
TL;DR: a system doesn't always have to be Turing complete to be a source of security issues. And accordingly, not everything that is a source of security issues is Turing-complete. But everything that's Turing complete can be a source of security issues. And everything that has security issues causes the necessity for those security issues to be mitigated. And almost every mitigation incurs a performance cost. UTF-8 is a particular encoding for Unicode. UTF-8 itself has security issues despite not being Turing complete. Unicode is Turing complete... Hilarity ensues.