I smell a bit of ignorance and a great deal of paranoia in this question. Bare metal installs of Linux are easy if you can build the boot media, and they are the most common way to run Linux. You've removed some of the paranoia, but I'll leave the related explanations here.
I'm going to ignore vague issues until you clarify in your question while trying to address things that appear more clear. (If you answer comments on the question by updating the question, I may revise this.)
Note that the linux boot logs and dmesg are full of debug messages, some of which mention transition states that are not the final system configuration and capabilities available that are not necessarily in use when booting is complete. Filesystems like /sys and /proc are virtual and are full of magical files that are created on the fly when you access them and do not behave like normal files. Similarly /dev is partially dynamic and is likely to have surprising things in it that do not mean much. Systemd is not a single program, but a suite of programs that work in tight concert. All of this can be confusing to someone new to linux which is why most distros start with a pretty splash screen that covers up boot messages.
ACPI is a standard programming interface between your OS and your hardware to manage power use and try to optimize battery life. It isn't necessary, but without it, your laptop can't properly sleep and unused hardware components can't be put into low power mode, and you can't monitor battery life, among many other power management features ACPI supports. Bios implementations of ACPI are notoriously buggy and/or incomplete, and the linux kernel complains when it discovers issues.
UEFI a new BIOS scheme for booting machines, and is specifically designed for (but not restricted to) 64 bit architectures. Without UEFI and accompanying GPT partition scheme, it is difficult to handle modern large disks and 64 bit hardware peripherals. UEFI is a miniature operating system itself intended mostly for boot loading and it is completely replaced in memory once your target operating system (Linux) is booted. Note that UEFI is not exactly new either. It's been around since 1990 and started becoming available on intel platforms around 2004.
setuid and setgid can be used in exploits, but in themselves, are not exploits. Those features have been around since at least 1972 in the earliest of the original Unix versions. These do not "fake" root access. You either have root access or you do not, and it doesn't matter if it is through logging in as root or through tools like su (also very old) or sudo. Most distros including Ubuntu will allow you to set a root password and log in directly on the root account, but this is generally considered sloppy practice and isn't necessary for normal system administration tasks for which sudo works just fine.
Despite early rumors around TPM, it is not an evil scheme (by Microsoft?) to prevent you from doing things on your computer. It is a method to allow verification of the boot environment of your computer. It does not prevent or interfere with your system in any way. Instead, if the verification succeeds, it allows automatic release of secrets stored in the TPM that you can use to do things like decrypt encrypted disks instead of supplying a password at every boot. There is nothing in TPM that you are required to use if you don't want to do that sort of thing. It doesn't matter if it is enabled or not if you don't use it.
The VT-X / VT-D features do not "enforce" virtualization. If you are using virtualization, VT-d allows passing hardware device access directly to a virtual machine without the host operating system needing to emulate them or even have a driver. If you are not using virtual machines, this feature doesn't do much. (However, it does interfere with some drivers in the host OS in some situations, so if you are not using virtual machines, turning them off might help, but otherwise doesn't matter.) There are several virtualization features in Intel cpus like VT-x, and if all of these are turned off, virtualization is disabled. VT-x in particular enables cpu instructions that are required for virtualization to work, so if you've disabled these features and still think you have a hypervisor under your Linux install, you are just paranoid. (This doesn't say anything about malware however.)
Hyperthreading is another CPU hardware feature, and has absolutely nothing to do with virtualization. Hyperthreading is a cheap way to make your processor appear to have more CPU cores than it actually does by sharing resources in a CPU core between multiple execution threads. If you are running code that doesn't make full use of the entire CPU core, hyperthreading may give a significant performance boost. When it doesn't work, it doesn't slow things down, it just doesn't make them faster either. You can turn this off in BIOS, or you can leave it on and just run fewer threads and then it won't be used. Hyperthreading is not inherently related to virtualization, but it may give the hypervisor a big performance boost.
grub2 is only tangentially related to PXE. PXE is a method that assists booting systems off of a network server instead of booting them off of local media. In enterprise environments, this is super helpful and typically faster than booting off of slow local media like floppies, cdrom, or even USB, but it is frequently only used for initial provisioning of machines. If you don't have a network boot server on your local network, PXE is useless and harmless. It is actually trivial to turn this off, and difficult to turn it on -- without a properly configured server, it does nothing. Grub can be booted with PXE, and may be able to load things through PXE servers, but grub doesn't require PXE or use it without being told to specifically. Note that careful examination of grub variables may turn up capabilities and commands for features you are not using. This doesn't mean those features are in use or active.
In your comment you mention 32-bit and 64-bit Linux and then mumble something about "no 32-bit software that could enable Win32 API". These are completely unrelated concepts. The Intel CPU, for backwards compatibility reasons, has a 32-bit mode and a 64-bit mode. This allows booting 32-bit operating systems on 64-bit processors (but if you've got >4G of memory, this is not an effective use of your hardware). Additionally, on these processors, Linux allows running 32-bit Linux executables even on 64-bit Linux. This has nothing to do with Windows or Microsoft, it's just a CPU feature that the OS supports. Again, if you don't have 32-bit executables, you don't need to use it.
WSL is a virtual machine that allows running Linux in a VM with windows as the host OS. If you are not running Windows, you are not running WSL2. This isn't something you can accidentally do or do without being very aware that Windows is the primary OS running.
DOS protected mode is a feature of Windows 3.0. If you are running Linux, you aren't using that at all. It might be involved in the bootloader, but that's long obsolete and not used on modern hardware, and disabled very early in the boot process as the kernel initializes the kernel environment.
Third party linux kernel modules are recompiled on kernel updates because the Linux kernel very intentionally only has an API, not an ABI for kernel modules. This has nothing to do with virtualization.
AppArmor and SELinux are not related to virtual machines. These implement security policies on your system to try to prevent compromise of the system by untrusted applications. On a default configured system, SELinux does almost nothing to constrain a logged in user, it is more concerned with constraining things like web servers and other similar externally triggered applications. Both SELinux and AppArmor are designed constrain system services from doing unexpected things, like for instance, your mysql database server scanning all the files on your system.
A default ubuntu installation may have Samba, Kerberos, and possibly ssh preconfigured, but that doesn't mean they are used. In particular, it takes extra steps (like logging into the server with an enterprise account) to configure Kerberos to talk to an enterprise server. In Ubuntu, ssh client should be installed by default, but openssh-server is only installed if you checked that box in the installer; however if it is installed is enabled by default.
You have not mentioned anything in your question that would provide evidence that your system is running in a VM or that your USB media is compromised, so I can't address those.
Virtualization doesn't "happen" accidentally on new hardware, It's something you have to very intentionally install. It is more likely that an enterprise environment would prevent you from writing boot media at all than for it to interfere with it and modify it as it is being written. Setting up something to do that is just too much work and would not be done in any normal environment.
I have not seen any radical changes in the way bare metal hardware works in the post pandemic era. Linux has changed to support cloud without using it if it isn't there, but the hardware has not changed this way. Your question is full of paranoid rantings about cloud use and virtualization that are unrelated to linux and installing linux. I believe you are looking at boot diagnostic messages and inner linux workings with no understanding of what you see and are seeing phantoms of virtual machine use and cloud usage that just doesn't exist. You have provided no evidence, not even transcripts of such messages, just uneducated guesses and delusional opinions with little clue as to what triggered them. Given evidence of what leads you to believe these things, it could be explained what is actually happening.
