Variables/Functions can be optimized out by the toolchain compiler for a variety of reasons.

If the optimization is left as "Default", with the Hardware debugger enabled the system will use -Og (debug optimization), and this should suffice in most cases for debugging.  No Optimization (-O0) can also work to avoid this, though may slow the program down, and increase the code size considerably.

Can you confirm (with example) what you are seeing that is optimized, which you want to inspect?

Also, the Visual Micro Serial Debugger avoids the optimization issue completely, and allows variable tracking, charting, conditional breakpoints, trace points and more via the Serial port.

Have you tried watching "mpu.getAngleX()" instead of "x"?
(In this case I expect the compiler can see it is assigned, just to be used with no other operations, so reduces this to essentially "Serial.println(mpu.getAngleX())")

The Visual Micro Serial debugger is the "Serial" option on the Debug Listing (set to Hardware to use STLink), and works slightly differently to the hardware debugger as no additional hardware is needed.  It is built into the Visual Micro Extension, so looks very similar from the UI as both are in VS.

The differences between these two debugging methods are listed below, with a vide example of the Serial Debug Charting in action.

Doc: Differences between Visual Micro Debugging, Gdb Debugging and Visual Studio's Debugging of Native Platforms
Video Example: Serial Debugger Charting with vMicro

Understood, there may be alternative options to step into the getAngleX() method to review this at runtime.

The Serial Debugger is a complete replacement for the Hardware Debugging, so the options cannot be selected together.   

It also requires the Serial output to work for the board in the Serial Monitor (which I believe is an issue for your configuration from the other thread), as this is what the debugger uses to send the messages to/from the board/pc.