It's a completely different language with different focus and features. "better" depends on the requirements you want to solve with the language. Rust can do memory management at compile time whereas Oberon and its descendants (such as my Oberon+ version) use a garbage collector at runtime. Rust is much bigger and more complex than Oberon, but it also has features which make it more suitable for systems programming. Simpler is not automatically better. If a language is too "simple" (i.e. minimalist), the complexity often shifts from the language specification to the application code, requiring more boilerplate or "clever" tricks to solve complex problems.
And it was not only simplicity (as Vidar assumed), but Oberon indeed had a different approach to OO in that there were no bound procedures, but the idea was (as you can observe e.g. in the Oberon systems and in publication by Wirth an his PhD students) that "type extension" (i.e. inheritance) is used to create extensible message hierarchies, which then are polymorphically handled by procedures accepting a VAR parameter of the most general message type. In this handler, the messages are dispatched by the IS operator or the WITH or CASE statement. This has similar effects as e.g achievable by sum types, and interestingly is closer to e.g. Alan Kay's view of OO than the implementation found in Smalltalk-80 (notably, Wirth arrived at this message-centric model independently of Kay’s work in the Smalltalk lineage).