This is a bit confusing because in Windows 8.x, “Windows Runtime” was actually used to refer to a few different things:

A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede “Win32” (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don’t depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers. The set of Windows APIs that follow the above pattern. A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10. In the Windows 8 days, these apps were called “Metro style apps” during most of 8.0’s public preview period, and officially dubbed “Windows Store apps” just before RTM. The platform/environment for these apps … officially didn’t really have a name (other than “platform for Metro style apps”). Unofficially, people (including at Microsoft) sometimes referred to it as “Metro” (a whole can of worms in itself) or … “WinRT”.

So what’s the relationship between WinRT “proper” (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless “platform for Metro style apps”? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface.

But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and “UWA vs. classic app” and “WinRT vs. Win32” are mostly independent; over time, they’ve gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).

So to summarize, it’s not technically accurate to say that “UWP replaced WinRT”, though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it’s just an updated version that’s been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.

As for WPF, it was a UI framework that originated at a time when Microsoft was trying to aggressively move all its platforms to managed code (i.e., CLR and .net). It’s mostly written in managed code and only exposes .net APIs. The Windows and Office teams ended up changing course away from managed code, and the WinRT XAML framework can be seen as a do-over of WPF that removes the CLR dependency, so that Windows/Office can use it, while still trying to expose a natural-feeling API for C# developers.