I think there is value in working with poorly written code. You will learn all the details of the language, because you will see many edge cases. You will learn about all the bad ideas (aka anti-patterns) so that you can avoid them. You will learn that comments are lies and that there are things that you can't trust. And hopefully, you will learn how to turn bad code into good code without introducing more bugs than you have fixed. If you end up coding for a living, you are more likely to see really bad code than good code. Not only because though budget cuts and the occasional mess up by incompetent coders, but also because good code simply works, and there is no need to touch it.

I totally agree with the "experiment" part though. Everything you learn is worthless unless you actually code something, preferably something useful.

On a more technical point, I think that terseness is undervalued. The first rule of good code, for me, is "write short code". There are a few exceptions but these are just that : exceptions.

I was writing from my own regret. I feel that I learnt surprisingly little by spending a decade rewriting badly written code. I should have found out what encapsulation was years earlier. Sure, there are lessons there, but I think you will pick most of them up anywhere; you're always exposed to code you don't like.

I still value terseness highly, as in my opinion it's strongly correlated with readability (though not at all when taken to extremes), but I very often have to increase verbosity to increase maintainability. E.g. don't take shortcuts that will leak through abstractions.