Even though this example has an easy workaround, it does seem like a scenario which could present issues in other deployments.

In the scenario where a standard application that doesn't exist in the target (ex. Sandboxes and LightningInstrumentation) is included in a deployment (along with its permissions), there's 2 problem analyzers that come into play

1. "Remove standard application additions/deletions from deployment"

2. "Remove items which reference the listed components which are not available in the target"

When both metadata types are selected (application and permission) only #1 is flagged. This means Gearset removes the standardApplication, but leaves the references to the application in the profile which causes the deployment to fail.

In retrospect, the changes made by analyzer #1 should either cause #2 to flag it or #2 should flag it in general since the application doesn't exist in the target.

The workaround is to make sure your CI jobs or deployments to sandboxes to do not include standard apps that don't exist in Salesforce. However, this puts the work/onus on the end user whereas the analyzer already exists to solve this for us.