No, you can use it in any app including "normal" Win32 apps. I've done it, it works. You can think of it as a plain upgrade over Win32.
The reason you think that is that once, it was indeed the API of UWP apps and those had various constraints as Microsoft tried to Apple-ify the platform. But they gave up on that a long time ago and got far more relaxed. Now you can mix and match old/new tech. You can ship Win32 apps in the app store, Win32 apps using MSIX, WinRT code using custom installers etc (the "sideloading" toggle switch went away a while ago for up to date Windows 10 machines, it still exists in Windows Server which is a fork of an ancient Win10 branch).
Caveat: some WinRT APIs want you to have "package identity", which (I think??) requires MSIX. This is not different to macOS though, where some APIs require you to have a bundle ID and be code signed. The OS wants to be able to have some stable identifier for an "app" which is allowed to change arbitrarily between versions. On macOS that identity is plumbed through Apple's in-house certificate authority through to a CMS signed CodeDirectory structure in the MachO headers. On Windows it's in some ways a bit simpler, in other ways, more complex - it comes from a combination of your code signing certificate and your package ID. There is an API and cmdlet for granting an app package identity without it being installed via MSIX but for some reason it's limited to developer mode. My guess is that MS will give up on that at some point and let old-style Win32 installers grant package identity too. The MS approach is there for a reason though, because the files installed via MSIX are "tamper-proofed" which prevents other apps from overwriting them. So, establishing the identity of an app installed this way is extremely fast and there's no way to hijack another app's identity by fiddling with its data files. If you look at how macOS does it, it's kind of painted itself into a performance corner by lacking this, the requirements on apps w.r.t. loading data files is very unclear, and they're still changing how they enforce code immutability even in Ventura as a consequence.
The reason you think that is that once, it was indeed the API of UWP apps and those had various constraints as Microsoft tried to Apple-ify the platform. But they gave up on that a long time ago and got far more relaxed. Now you can mix and match old/new tech. You can ship Win32 apps in the app store, Win32 apps using MSIX, WinRT code using custom installers etc (the "sideloading" toggle switch went away a while ago for up to date Windows 10 machines, it still exists in Windows Server which is a fork of an ancient Win10 branch).
Caveat: some WinRT APIs want you to have "package identity", which (I think??) requires MSIX. This is not different to macOS though, where some APIs require you to have a bundle ID and be code signed. The OS wants to be able to have some stable identifier for an "app" which is allowed to change arbitrarily between versions. On macOS that identity is plumbed through Apple's in-house certificate authority through to a CMS signed CodeDirectory structure in the MachO headers. On Windows it's in some ways a bit simpler, in other ways, more complex - it comes from a combination of your code signing certificate and your package ID. There is an API and cmdlet for granting an app package identity without it being installed via MSIX but for some reason it's limited to developer mode. My guess is that MS will give up on that at some point and let old-style Win32 installers grant package identity too. The MS approach is there for a reason though, because the files installed via MSIX are "tamper-proofed" which prevents other apps from overwriting them. So, establishing the identity of an app installed this way is extremely fast and there's no way to hijack another app's identity by fiddling with its data files. If you look at how macOS does it, it's kind of painted itself into a performance corner by lacking this, the requirements on apps w.r.t. loading data files is very unclear, and they're still changing how they enforce code immutability even in Ventura as a consequence.