I have identified the root, root cause of the problem in @elvisbegovic’s one-line reproduction. This is probably not the general problem for other commenters on this issue but see the bottom of my analysis for ideas in those cases.

1. The root cause is actually that angular-tree-component’s UMD build is not valid. Their use of rollup does not specify mobx, mobx-angular and lodash as external packages, which leads to the UMD bundle including these packages inline. Note that the ESM files do not bundle up these external libraries and instead imports them as expected.
2. ngcc computes dependencies between packages before processing them; it must ensure that packages are processed after their dependences. Do do this it parses just the first of the code formats that it recognises. Because it considers the package.json properties in this order - ['fesm2015', 'fesm5', 'es2015', 'esm2015', 'esm5', 'main', 'module'] it finds the main property (UMD) before the module property (ESM). So ngcc was using the broken UMD format for computing the dependencies and so missing the mobx-angular package.
3. Since mobx-angular was not found as a dependency of angular-tree-component the former was being processed “after” the latter, which meant that angular-tree-component had a missing dependency when it came to processing the ESM format (aka module).
4. The missing dependency during compilation can be identified as an error but is currently being swallowed.
5. The compilation (and so the ngcc processing) completes “successfully” but the directives used by the component are not generated in the rendered output, leading to the runtime errors we see here.

Possible resolutions:

1. Workaround by adding a ngcc.config.js that hides the main property in angular-tree-component so that we always use the module property for both processing and for dependency resolution.
2. Fix angular-tree-component - provide a PR to fix this package’s distributable (https://github.com/500tech/angular-tree-component/pull/771)
3. Change the order of dependency resolution properties, so that module is before main. I think it was originally in this order because it was felt that a single flat file would be parsed faster than having to load up a deep non-flat hierarchy of files; but it is also reasonable to assume that main is more likely to be “broken” than module in 3rd party libraries out there.
4. Add better diagnostic reporting to ngcc to help diagnose these scenarios. PR here https://github.com/angular/angular/pull/33964

With the change to the diagnostics reporting we get:

Compiling angular-tree-component : module as esm5
console_logger.ts:38
Error: Failed to compile entry-point angular-tree-component due to compilation errors:
node_modules/mobx-angular/dist/mobx-angular.d.ts(5,22): error TS-996002: Appears in the NgModule.imports of TreeModule, but could not be resolved to an NgModule class

which at least will tell us where to start looking and not leave us with an obscure runtime error.

I can confirm it works!!!

Having this temporary ngcc.config.js with (if I understand):

module.exports = {
  packages: {
    'angular-tree-component': {
      entryPoints: {
        '.': {
          override: {
            main: undefined
          }
        }
      }
    }
  }
};

Or removing this line "main": "dist/angular-tree-component.umd.js", in node_modules/angular-tree-component/package.json

Then rerun ngcc, makes our large-app working with ivy!

By the way, doing this first ng serve always throw this warning:

WARNING in Entry point 'angular-tree-component' contains deep imports into 'C:/Users/xxx/node_modules/lodash/defaultsDeep', 'C:/Users/xxx/node_mo
dules/lodash/get', 'C:/Users/xxx/node_modules/lodash/omit', 'C:/Users/xxx/node_modules/lodash/isNumber', 'C:/Users/xxx
/node_modules/lodash/first', 'C:/Users/xxx/node_modules/lodash/last', 'C:/Users/xxx/node_modules/lodash/some', 'C:/Users/e.begovic/WebstormProjec
ts/i10/node_modules/lodash/every', 'C:/Users/xxx/node_modules/lodash/compact', 'C:/Users/xxx/node_modules/lodash/find', 'C:/Users/e.begovic/Webst
ormProjects/i10/node_modules/lodash/isString', 'C:/Users/xxx/node_modules/lodash/isFunction', 'C:/Users/xxx/node_modules/lodash/throttle', 'C:/Us
ers/xxx/node_modules/lodash/includes', 'C:/Users/xxx/node_modules/lodash/pick'. This is probably not a problem, but may cause the compilation of
entry points to be out of order.

Thank you @petebacondarwin