Game design theory, even at its most practical, is incredibly hard to apply to game development because game development is a highly intuitive process. The more complex a game gets, the more intution driven the development process becomes, because the possibility space becomes unmanageable.
The developer's tiny brain can only think of so many things at once. Trying to visualize something is even more difficult. Because of this, at any given point of development, the dev is only going to be working on specific aspects of their game - chunks of the possibility space, specific interactions, slices.
What I found to be most effective so far is to think of practical theory not as a map, but more as a magnet applying steering force to a dev's brain and as a nice hefty slap across the face for a factory reset.
You want to build catchy rules of thumb that put the dev in a desired mode of thinking, steering their attention and making them focus on the right things. Simple words or phrases that can be said out loud and instantly make your mind race towards a large amount of related associations. Derek Yu's Bigness concept is my favorite example of this - as soon as I utter it my brain goes through things like using signifiers, leaving in mechanics I feel are too redundant, a very vivid idea of what "fiddliness" feels like, ARPG fans being obnoxious, etc. The simpler, clearer and more versatile your mental image is, the better. Ideally you should be able to smell and taste it, too.
Comparison is a very powerful tool - build up the image of the concept, but also build up its opposite or its absence, tie it to games the dev likes and dislikes. This creates stronger webs of associations, and possibly emotions. You want to somehow tap into the realm of feelings and intuitions. If people start wondering how your concepts apply to this or that game long after they finished listening to or reading your stuff, you know you're on the right track.
The other useful type of design theory is dev "life hacks" - things anyone can instantly apply to their games. Trying to find examples like this which naturally follow from your general game design concepts is very important. And once again, pointing to concrete examples is also important, and not just once or twice but constantly - effective teaching of game design concepts is a gradual process of rewiring someone's brain.
And of course the ultimate filter is using your concepts in your own games or while giving playtesting feedback for others - the most effective stuff will have tangible results.
The process is actually kind of similar to a lot of what you see in marketing, so maybe going through cognitive biases and checking how to capitalize on them might be fruitful.
But realistically it's probably better to just play & make more games.
