A support case was opened for this issue and has been resolved.

Here is a brief explanation about how direct email approval works in Forms:

When you set up direct email approval, Forms will send an email to the user that's been assigned to the user task. This email (i.e. reference email) is the one that contains the X-LFFORMS header. Note that a copy of this email is also sent to the account that's been configured as part of the FormsConfig > Email Approval Server settings. So when there's a new task, Forms will send an email to the approver for direct approval while also BCC'ing the IMAP account that's configured to handle direct approval processing.

When the user actually replies to the email, this email (i.e. reply email) will be sent to the same account configured in the Email Approval Server settings. Forms will only look in the "root" inbox folder of this account for this reply email.

In the reply email, there is a header named "In-Reply-To" which contains a value that should match with the "Message-ID" header in the original reference email. This is how Forms will associate the reply to the correct reference email. Once it finds the matching reference email, Forms will then use the X-LFFORMS header in that reference email to get the resume ID of the Forms instance that it needs to act on.

In this support case specifically, the issue was that the reference email that was BCC'ed to the IMAP account was getting routed to a subfolder via a routing rule. The actual user reply email was remaining in the top level inbox folder. This was preventing Forms from being able to match up the reply email to the original reference email. Once this was sorted out and both emails were going to the same root location, then direct email approval worked fine.