I'm having trouble on how to bring this up without sounding condescending/arrogant though, as I feel that's how I would come across if I straight up told a developer with multiple years of experience he should learn such a "basic" skill. How do I best approach this?
Then the simple answer is: don't.
People have different skillsets, abilities and aptitudes, and what one person will consider "basic", for another may be very exotic and alien if they come from a different backgrounds. If you need a practical example, someone coming from say database engineering background may be very alien indeed to asynchronous, but to him a more API-oriented developer questions about data structures could equally be seen as "basic".
As you are not a leader of the team, it's not your responsibility or even prerogative to tell him to:
sit down for a few hours, read an article or two about how and where to use it and code a few examples with it
It's simply not your job and from what you describe this is how the company is intentionally setup. And the best you can do is to keep showing him a way to what you consider a better way during reviews, but you cannot force him down that path. As this is ultimately what you want to achieve, but it simply is beyond your reach.
Of course if there are serious issues coming from that supposed lack of "basic" knowledge (and I cannot express enough how "basic" is not universal) then you must raise this with whomever the boss is, and explain in very specific term what is the actual harm caused by behaviour X. And I mean example like "because Foo doesn't understand Async operations, the ticket he was working on was delayed, and we had to delay release of X which impacted business in Y way.". If it's not severe enough that you can come with realistic examples of that, best not to rock the boat and possibly turn the relationship into an adversary one. More so as you would be the one overstepping bounds in it.