The only involvement of the secure element in disk encryption is the Weaver feature explained in https://grapheneos.org/faq#encryption. OS derives a key from the lock method via scrypt, then derives purpose-specific tokens from it via SHA512 with a personalization string, which is done to avoid the initial credential-derived key being directly used for each different purpose. One of these tokens is sent to the secure element as part of Weaver and if it's correct, the OS gets back a previously randomly generated token from Weaver needed for key encryption key derivation. The OS passes a credential-based token and the random token from Weaver to the TEE which performs the final hardware-bound key encryption key derivation. The key encryption key is then used to decrypt the disk encryption keys within the TEE. The disk encryption keys were randomly generated when the user profile was created. On the Pixel 6 and later, the TEE then sets up the SoC disk controller's inline encryption and the OS uses that via handles. On earlier devices, the Linux kernel receives the disk encryption key and sets up the inline disk encryption hardware itself. Avoiding the OS getting the keys is the wrapped key feature, aimed at making it harder for an attacker to leak the keys. For example, if an attacker leaks data from the kernel, they can't get the disk encryption to use them at a later point with physical access to the device.
The secure element provides the StrongBox keystore, which is unrelated to the OS disk encryption. However, it can be used by apps for their own additional layer of encryption such as to keep data at rest when the device is locked. Apps can generate within the hardware keystores or import keys into them. Hardware attestation is tied to keys generated in the hardware keystores. Apps can decide the constraints on the keys, such as whether they're available when the device is unlocked. If they aren't available while unlocked, the hardware keystore implementation could encrypt them with the token it receives derived from the lock credentials but this is a quality of implementation issue and for the most part it's not specified how these things are implemented.
Pixel 2 added an NXP secure element with Weaver and insider attack protection. This was replaced with a standard ARM Cortex secure element in a custom SoC (Titan M). This was later replaced with a fully custom RISC-V core with the Titan M2. Titan M2 significantly reduced attack surface and has greatly reduced the density of serious vulnerabilities. All of these chips have physical anti-tampering and the most realistic attack route has been exploiting the firmware. That may be changing with the Titan M2 as they've significantly reduced attack surface and hardened the firmware. It will hopefully reach the point where finding serious firmware vulnerabilities becomes impractical. The physical anti-tampering will then become increasingly important.
For disk encryption, the secure element is there to provide bonus security via aggressive time-based throttling. The scrypt-based key derivation and TEE hardware bound key derivation approaches predating it are still present and have been improved. These hardware features are what provides security for weaker lock methods. A random 6 digit PIN is entirely dependent on the secure element throttling while a random 8 diceware word passphrase doesn't need any of the hardware security features but still gets them.