Unless you're communicating all of this with your managers/supervisor/team, this is a fool's errand.

I would most definitely discourage this advice, in my opinion it's dangerous. Instead, I would focus on slowly and "casually" refactoring bad parts (without putting significant extra hours at all), while making sure that the code is actually badly written, and it's not just "not written your way" or "code I can't understand because I didn't study it enough". I have seen many engineers being victims of these two points. Sometimes the code just appears badly written because you don't have enough context to see that it's not.

I would stress that rewriting it only to discover oh, so that's why they did it that way is one of the most disheartening exercises in our industry. Documentation is what clarifies the 'wtf' moments in reading code since even initially pristine architecture will become contaminated by edge cases over time.

I give 100% that after you did your re-write and then left for another company next set of developers will think exactly the same thing about your codebase. 100%.