The short answer to your questions is that “yes, it is better to use basic multi-track events than simple events where possible.”
However, the reasons why are bit more complicated than just system resources, and requires some discussion of what simple events are and how they came to be.
Back in the days of yore, when Designer was yet young and middleware, itself, still seemed somewhat novel, ‘Multi-Track Events’ were the only kind of event that Designer had. Of course, since there was only one kind of event back then, we just called them ‘events,’ and for a long time we thought that events (and perhaps an interactive music system) were all we needed. Still, after a while we noticed that most users would have at least a few events that were very simple: One layer and one sound def, with no parameters, effects or user properties. Unfortunately, such simple events still used the same amount of system resources that more complex events did - and that was clearly no good. So, we implemented a series of optimisations that meant that these simpler kinds of events would automatically use a little less resources at run-time than standard events.
To differentiate between the two kinds of events, we called the stripped-down, optimised events ‘Simple’ and the traditional, feature-filled events ‘complex.’ This is where things can get confusing. The ‘simple events’ I just described weren’t the simple events you know today. They were actually what we now call ‘basic multi-track events.’ Bear that in mind as you read the next few paragraphs.
We had hoped that the distinction between simple and complex events would make life easier for our users, and it did - but it also caused some confusion, since the Designer interface was never that clear on what the difference between a complex and a simple event actually was. We did display those little ‘Red C’ and ‘Green S’ indicators on each event icon but they weren’t immediately obvious, and it was quite possible to make a whole slew of changes to a simple event and only notice that it had become complex sometime later, without it being obvious which particular change had made the difference. Worse still, a lot of people didn’t even realise that complex and simple events existed, and thought that the little red ‘C’ meant that they’d done something wrong. We tried putting the information in the manual, but it turns out that a lot of people don’t read manuals, or only read the parts that seem most interesting, so a large number of users still didn’t know what what was going on.
Eventually, we decided that the only way to make simple events obvious was to give them a completely different interface. Our lead UI designer carefully devised and refined a new design, and compared to what had been before, it was beautiful. Simple events would have their own context menu, and a streamlined interface that only presented the features that simple events used. The sound def interface would be built-in, since with only one sound def per simple event, there was no need to keep it seperate. The property sheet was be simplified, the unnecessary and distracting was stripped out, the most commonly used features were presented in the most appealing and obvious way… And that was the beginning of simple events as you know them today.
We kept the old simple events, of course, to avoid compatibility problems, but we renamed them ‘basic’ instead of ‘simple’ to avoid the two getting confused. While we were at it, we started calling non-simple events ‘multi-track,’ since it was a more descriptive name. With that, it was obvious what simple events could and couldn’t do, it was clear when an event wasn’t a simple event, and even without the manual it was obvious what simple events were.
…And that’s the history of how simple events came to exist in the form they have today, more or less. That line from the manual that you quoted, the one that says “Due to the optimized code and data path, Basic Multi-Track Events use significantly less resources than standard events” should really read “Due to the optimized code and data path, Simple Events and Basic Multi-Track Events use significantly fewer resources than Complex Multi-Track Events.”
Except that there was still one fairly significant problem. We had introduced the new style of Simple Events at a time when we were really ramping up into intense development of Studio, and ended up not having the time to implement one particular feature: The ability to convert simple events into complex multi-track events. Without this feature, the limitations of simple events become constraints on what a user can and can’t do, and artificial constraints can get annoying if your project’s requirements change.
As a result, we reccomend that if you’re even remotely uncertain whether an event is going to end up being complex or simple, it’s best to use multi-track events.