I don't. I worry about getting it working first.
When I first started coding, I was constantly questioning everything I did because I was worried about writing code that did not fall under some set of "best practices", like I was going to be graded on it. It took some time, but one day I realized that I was spending most of my time trying to adhere to someone's opinion and I didn't know why. I was a cargo cult programmer. (hat tip to @Dipscom for showing me that term)
All this means is don't write the same code repeatedly. If you're typing a similar block of code more than 3 times, there's a good chance you can refactor it into a single function/method or other mechanism like a loop. If it's too hard to refactor, makes your code harder to read, or adds unnecessary complexity, then it might not be worth the refactor.
Google some of the problems with premature optimization. GSAP is already highly optimized, so there's not much you can do to make it run faster. If performance is a problem, then you should look at the properties you're animating. Anything that triggers a layout or paint is a potential bottleneck.
Your settings object is way too granular. It looks like you're defining your entire app inside of it, and it's very hard to follow because it's nested way too deep. The advice @Sahil gave about breaking it down into specific settings is a good idea.
You may also want to look at using Object.assign() for default or extending settings.
Why does that irritate you?
Sure, querying the DOM can be slow, but I think what @PointC did in his Star Wars demo is fine because it's all done upfront, and he has no need to reference any of those elements again. Once an animation is created, it's not going query the DOM again, but you can always pass a real element into a function.
And note that keeping references to objects can lead to memory leaks if you're not careful. The elements that you're storing in your settings object are going to remain there until you remove them.