The EtreCheck report actually points pretty strongly to the internal HDD/APFS I/O path rather than a bad container layout. Your 1 TB 5400-RPM disk is only managing about 54 MB/s reads and 47 MB/s writes, while apfsd is repeatedly consuming ~86% CPU, which is a big clue that the system is spending excessive time servicing APFS filesystem work on a very slow mechanical device.... APFS is particularly unforgiving of random I/O and metadata-heavy workloads, so once macOS starts doing filesystem housekeeping, snapshots, indexing, VM activity, or other concurrent I/O, the whole UI can appear to freeze because processes are waiting on storage, not because Finder itself has crashed.
The fact that booting Sequoia from an external SSD makes the machine usable is an important diagnostic result and makes the internal drive the first thing I would suspect. I would leave the existing APFS container and its system/data/preboot/recovery/VM volumes alone and use the external SSD as the startup disk... if you want to confirm the diagnosis, compare the machine's behaviour while the internal disk is largely idle versus when it is being accessed, and check the internal drive's SMART/health and system logs for I/O errors or APFS-related messages.
If the external SSD remains stable while the internal HDD produces beachballs, high apfsd activity or I/O errors, replacing the internal HDD with an SSD is the real fix, not deleting APFS volumes.