WITH SECURITY_ENFORCED and Security.stripInaccessible in a single SOQL

Currently if you include a field in a SQOL query that a user doesn't have access, the field is returned and can be used by the code, thus exposing the data to someone that should not have access to it.

This new clause is a blunt way to ensure your code isn't provided access to fields that an admin may have specifically restricted access to via the profile. It does this by throwing an exception if there are any fields in the query that the context user doesn't have access to.

This feature is tailored to Apex developers who have minimal development experience with security and to applications where graceful degradation on permissions errors isn’t required.

You may want to use the isAccessible or similar fields to provide a better experience to your users, but that requires more logic and error handling. I highly doubt they'd be deprecated as they give the developer much more control when handling FLS.

If a field is hidden, the exception will bubble up to whatever the calling code is.
e.g. If it's a controller on a page, and you have the pageMessages on your VF page, then the exception will be shown there.

I'd recommend using the stripInaccessible method to figure out exactly what field isn't accessible.

Change your query to not use WITH SECURITY ENFORCED and pass the query into the stripInaccessible method. You will get a SObjectAccessDecision that contains the removed field names. (code below mostly taken from documentation).

SObjectAccessDecision securityDecision = 
         Security.stripInaccessible(AccessType.READABLE,
                 [SELECT Name, BudgetedCost, ActualCost FROM Campaign]
                 );

// Get the removed field names - these are the fields they don't have read access to.
System.debug(securityDecision.getRemovedFields().get('Campaign')); // put sobject here

Edit: In Summer 20 notes, there's a mention that you can use stripInaccessible method to enforce field and object-level security for relationship fields. This seems to imply it didn't work before on relationships (or perhaps was unpredictable) which may explain why it might not have worked for you.