Within a lineage of languages, there are generally a lot of structural similarities because languages have influenced each other. The more languages you know, the less likely any given feature or behavior is to be totally novel — you’ll have already been exposed to something similar in another context. And, almost all popular & mainstream languages are heavily influenced by a particular lineage (ALGOL-60, usually by way of C) — in other words, you can easily learn dozens of languages without ever going outside a very small and specific corner of programming language design (wherein all the language design overlaps substantially). When you’re familiar with a lot of languages in a particular lineage, actual differences between them start to come down to trivia — either differences in the naming of particular things, or differences in the behavior of obscure edge cases that any maintainable software will specifically avoid. (In the domain of languages that are specifically designed to be legally-distinct duplicates of other languages, there’s even less effort involved: if you know Java, you can read & write C# too, and you can spend most of your time not worrying about the differences between them.)

Learning a lot of languages will also help with figuring out which features are most salient to real code & can be prioritized — which means that you can fairly easily write, read, and maintain code in a language you don’t *really* know. You can float in a level of shallow understanding of the underlying language for a long time (depending on your familiarity with similar languages) and only periodically dive into the mechanics or behavior of some commonly-used feature as you notice that it works differently than expected. (I spend a lot of time at work writing or maintaining code in javascript, julia, and perl — all languages that I wouldn’t say I actually know — and perl is the only one of the bunch where understanding existing code & writing competent- and idiomatic-looking new code requires substantial effort.)

Another skill that experienced programmers sometimes have that helps with learning languages is an understanding of how the parsing and lexing stages of compilers work. Language designers tend to make decisions iteratively during development, rather than writing a spec before writing any code, which means that ease of implementation affects the way languages are designed. If you know how to write a programming language, then you can put yourself in the mindset of the designer behind some other language and work out their thought process, thereby figuring how how some feature might work or how some behavior might be defined (because in your mind you reimplement that feature). This can backfire if the language comes from a different lineage or tradition & the designer has a different philosophy than you do (for instance, languages like haskell tend to go out of their way to perform bindings late, functional languages tend to prefer recursion over looping, and there’s a whole bestiary of different ideas about how types ought to work, all of which can lead one astray), but being wrong when using this method is also a learning experience, and having a deep understanding of how the compiler works & how language designers think can come in handy in a variety of contexts.