Avoiding verbose compositional class design
Question

*&quot;...so how is one supposed to avoid all the duplicated methods in choosing composition over inheritance?&quot;

I assume you are talking about JavaScript.
It might be a minor point but In JS we use functions, methods are reserved for the engine where the name comes from the language it is written in V8 for example is written in C++
Duplicating functions
There is no need to duplicate functions no matter how you create your object in JavaScript.
I just can not workout why you would want to do
From your bottom snippet

mthTen() {                // WHY??????
    this.math.mthTen()
}


Examining your example via rewrites
Defining the objects
const Events = () =&gt; ({evOne() {}, evTwo() {}});
const Maths = () =&gt; ({mthOne() {}, mthTwo() {}});

BTW Use literal if you don't need closure
BTW  you would only define objects (using this pattern) via functions if you were closing over some encapsulated data. They are better defined as literals in this case, avoiding the creation of unused closure for each object
const events = {evOne() {}, evTwo() {}};
const maths = {mthOne() {}, mthTwo() {}};

At the object level
If you want the functions to be accessible at the object level you may build it as follow
const createFoo = (math, events) =&gt; ({...math, ...events});
const obj = createFoo(math, events);

// Calling
obj.evOne();
obj.mthOne();

At the object property level
To create them as named properties
const createFoo = (math, events) =&gt; ({math:{...math}, events:{...events}});
const obj = createFoo(math, events);

// Calling
obj.events.evOne();
obj.math.mthOne();

As static functions
In many cases you would use them as static functions.
// static instance reference. There is only one math and events for many Foos
const Foo = (math, events) =&gt; ({math, events});
const obj = Foo(math, events);

// Calling
obj.events.evOne();
obj.math.mthOne();

Or
// Static instance. There is only one instance of math and events referenced by the constructor  Foo
const Foo = Object.assign(() =&gt; ({}), {math, events});
const obj = Foo();
// Note access via the instantiation function  Foo
Foo.events.evOne();
Foo.math.mthOne();
obj.event.evOne(); // will throw as it does not exist.

Or
// Static instance functions. There is only one instance of math and events 
// referenced via functions of the constructor  Foo
const Foo = Object.assign(() =&gt; ({}), {...math, ...events});
const obj = Foo();

// Note access via the instantiation function  Foo
Foo.evOne();
Foo.mthOne();
obj.evOne(); // will throw as it does not exist.

Note there is no formal way to define static functions its only static by how it is used and instanced (Via the class syntax static is just syntactical sugar for (assign to constructor, rather than prototype))
If you must duplicate
Warning Don't do this at home, it is only as an example. Doing this in any code can result in severe confusion and eventual application death.
If you really wanted to have a second copy of each function. eg obj.evOne and obj.event.evOne You can automate the function creation, binding the copied function references to the object you want as this


const events = {evOne() {}, evTwo() {}};
const logger = {
    logA() { console.log("A" + this.count++)},
    logB() { console.log("B" + this.count++)}, 
    count: 0
};

const addFunctions = (obj, ...instances) =&gt; {
    for (const instance of instances) {
        for (const [name, func] of Object.entries(instance)) {
            func instanceof Function  &amp;&amp; (obj[name] = func.bind(instance));
        }
    }
    return obj;
}

const createFoo = (a, b) =&gt; addFunctions({logger: a, events: b}, a, b);
const foo = createFoo({...logger}, {...events});

foo.logger.logA();  // should be A0
foo.logA();         // should be A1
foo.logger.logB();  // should be B2
foo.logB();         // should be B3



Question

&quot;What would the draw backs be compared the style of composition where each class you compose with is given a field name (I'm calling this named composition)?&quot;

This question is way too subjective to answer in any death.
There are drawbacks to every pattern, how the drawbacks effect the code quality is very dependent on the coders skill and level of experience.
If you are comfortable with a pattern and have the experience your proficiency outweighs any pattern's drawbacks.
The biggest drawback to any pattern is how experience a coder is in using it.
To be a well rounded coder you must gain proficiency in all the patterns.