Your suggestion to structure the ‘journey-discussion’ via slices or however this shall be named is important. Ideally, each slice with some back-up or plan B option (which could be somewhat secured on specification/interface level only, also avoiding to divert effort but structure alternative discussions a bit better and be able to have some leveraged strategy).
Anticipation remains key, not for speculation but to be able to act on time (be able to read various signs/trends); in case one ‘slice’ is under fire, lost traction or support; a replacement initiative could be timely engaged. Anticipation and flexibility: if some ‘slice-architecture’ is not established a fire or crisis in one key area may drag the whole full stack down ('ships have still compartments to lock full flooding / draining).
Also, having only Apollo as efficient hosting is a nogo for most larger companies (lock-in risks are much to high; here there must be two redunant ‘slices’ companies / services at least if this should scale up and sustain, this competition is also requied to scale-up Apollo).
FYI: This input is based on 43 years IT experience - Meteor encounter some 3 years ago during regular IT evolution/evaluation tracking (so far mainly checked performance on deep lists via JSON MongoDB imports), browsers perf. vs. Angular /React and follow re-run on new versions. Yes 1.5 seems pretty good (no regression seen yet).
Then, Meteor was/is a great full stack I recommended to check for (architecture / process - UX cycle speed) learning or to start some pilots (large company).
Consider, each slice will get under fire periodically or will encounter the better solution and needs to be replaced (reason I put my years IT exp.). On the positive flip-side the decision may come from the Meteor community to replace (for a better solution) a slide. Dependencies (License) are also becoming more and more complex, obscure to manage (e.g. React).
Congratulations to core team and contributors , Hope you will stay engaged and motivated.