My "taste" (like perhaps all other "tastes") comes from experience. Cliche, I know.
When you have had to tackle dozens of frameworks/libraries/API over the years, you get to where you find you like this one, dislike that one.
Get/Set, Get/Set… The symmetry is good…
Calling convention is to pass a dictionary: all the params are keys. Extensible, sure, but not very self-documenting, kind of baroque?
An API that is almost entirely call-backs. Hard to wrap your head around, but seems to be pretty flexible… How better to write a parser API anyway?
(You get the idea.)
And as you design apps/frameworks yourself, then have to go through several cycles of adding features, refactoring, you start to think differently about structuring apps/frameworks that make the inevitable future work easier. Perhaps you break the features of a monolithic app into libraries/services…
None of this is novel, it's just that doing enough of it, putting in the sweat and hours, screwing up a number of times) is where "taste" (insight?) comes from.
It's no different from anything else.
Perhaps the best way to accelerate the above though is to give a junior dev ownership of an app (or if that is too big of a bite, then a piece of a thing).
"We need an image cache," you say to them. And then it's theirs.
They whiteboard it, they prototype it, they write it, they fix the bugs, they maintain it, they extend it. If they have to rewrite it a few times over the course of its lifetime (until it moves into maintenance mode), that's fine. It's exactly how they'll learn.
But it takes time.