If we’re talking recording, it doesn’t matter that much how exactly you arrive at some fixed audio sequence. Indeed, use loops or goats, borrow $xxxxx gear from friends, pull multi-terabyte libraries of perfectly sampled cello—as long as it floats your boat (and your target audience’s. If you make stock progressive house for clubs, goat involvement probably isn’t worth it). By way of knob tweaking and some applied randomness you arrive at a take you like and then you delete everything else and let the goat roam free.
Things are different if we’re talking live performance. You’d be fine with that multi-terabyte cello library on stage, but not if sampling plugin brought opaque nth-party dependencies you can’t vouch for and have no time to properly wrap your head around. You don’t want surprises and you want to know for sure there’s enough performance leeway on your concert laptop.
There are steps you’d take to reduce the error margin while you perform that have no parallels in software engineering realm. Maybe you’d bounce your cello loops to audio to never have that computation happening in real time. Maybe you’d bring analog synths, which are bulky and pricey but also simpler conceptually, self-sufficient, well-tested and never give blue screen of death.
Your song is essentially being created every moment your program is running or being developed. You’re putting even more trust in what you’re pulling—the black box abstraction boundaries around your dependencies can contract, the input you receive from audience is more direct, and importantly there’s no you actually playing instruments and directing the performance because the whole behavior is defined by algorithms that often end up partly delegated to dependencies.