Impossible to help you without knowing which STM32 (the I2C peripherals are very different between them and some have notorious bugs - e.g. STM32F103!), without seeing your actual board and the rest of the code, including clock set up and initialization.
Put an oscilloscope/logic analyzer on the bus and check whether it is actually talking over I2C at all (and what exactly is being sent!) or whether there is some other problem. I would even suggest connecting something like an I2C eeprom and first making the STM32 code work with that instead of trying to fix both firmware and a potentially temperamental MPU at the same time.
I2C configuration on STM32 is complex and it is easy to screw it up. Also HAL is not exactly bug free and issues like "forgetting" to actually turn the peripheral on by setting the necessary enable bit are very common in the HAL code - it will configure everything except turn the thing actually on. Do verify that whatever it writes into the registers actually matches what the datasheet says needs to be set!
BTW, check whether HAL is converting between the read and write addresses itself or whether you need to pass the properly shifted address already (your code has MPU_ADDRESS_READ defined but you are reading from MPU_ADDRESS

)
FYI, these Invensense MPUs (MPU6500, MPU6050, MPU9250, etc ...) are notoriously finicky and love to hang/crash at the slightest provocation, e.g. whenever they don't like some configuration setting (and there are tons of those!). Also, if you don't properly pull-up/down (don't recall which out of top of my head) the pin that selects between the SPI/I2C modes it will randomly switch - typically in the middle of the I2C transaction! The documentation doesn't say anything about needing a pull-up there or this behavior and didn't show the necessary resistors on the pins in the reference circuits either. You will just get a hanging I2C bus and an IMU that stops talking to the CPU at random moments. That has costed me quite a few grey hairs in the past.