While it’s true that today’s SystemVerilog RTL synthesis tools don’t support hardware descriptions employing class objects, that’s never been because of theoretical obstacles.
Beneath the convenient abstract datatype machinery, a class object isn’t much more than a dynamic struct variable. Because the RAM-oriented simulation semantics must be mapped onto a fixed 2D computational grid, some subset restrictions would need to be imposed to bound the number of objects whose states are preserved across clock cycles. But there’s nothing new about such subset restrictions in design.
At time 0, when class objects could be used like interface instances, such bounds aren’t even required. As with const variables, time 0 can be thought of as the last step in elaboration, instead of the first step in simulation.
For class objects that are constructed after time 0 and persist across clock cycles, it’s probably sufficient to prohibit the use of recursively defined classes. (For example, lists and trees.) If such class objects were passed from one module to another, then additionally by the end of the clock cycle there would need to be no references to them in the source module.