This is your opinion, and is ok ... my problem is mainly that is presented as fact, when it isn't.

// I agree that we should avoid "falsy" values, so for that you can just combine
// optional chaining with nullish coalescing and default to `false` if the value
// is `undefined`, making the value always an actual boolean.
if (user?.credentials?.notExpired ?? false) {
    user.login();
}

// This is also ok, if the function exists you call it, if it doesn't, you don't.
user.functionDefinedOrNot?.();

// If the function returned a value, then ideally you should use nullish
// coalescing again.
const value = user.functionDefinedOrNot?.() ?? "default";

You say that it "seems compact", but it IS compact. You also say is "hacky", but...

// This (the old way of "solving" the problem):
if (user && user.credentials && user.credentials.notExpired) {
    user.login();
}

// If way more "hackier" than this:
if (user?.credentials?.notExpired ?? false) {
    user.login();
}

// And doing this:
if (user.functionDefinedOrNot !== undefined) {
    user.functionDefinedOrNot();
}

// Is EXACTLY the same as doing this:
user.functionDefinedOrNot?.();

Your proposed "solutions" are to either take more memory with default values (in the case of the object), or do an unnecessary checks that are already done for you with optional chaining (in the case of the function). You can see how TypeScript handles optional chaining when compiled as ES5 here, but the long story short is that is pretty much the same as what you did with the if, but with less boilerplate.

Now don't get me wrong, I agree with your point about how null should be avoided (I even wrote about that on a post of mine), but undefined is ok, and both optional chaining and nullish coalescing are great tools to deal with possible missing values. Writing your own "abstraction" of nullish values serves no purpose other than over-engineering and over-complicating a simple language feature.

One thing that we need to keep in mind as developers, is that stuff that looks like a "good practice" in a language, doesn't necessarily translate to a "good practice" in another language (and it could even be consider bad). Case in point is that Java is an OOP language with strong use of classes, which I already discussed several times here in DEV are terrible in JavaScript (and I would even say are terrible in general), because they provide a really poor form of encapsulation and reuse, compared with just using functions, modules and composition. So maybe from a class mindset it makes sense to avoid language features such as optional chaining, but it definitely doesn't make sense from a JavaScript point of view, when it actually helps you write less boilerplate to achieve the same goal.

Is almost like when those devs that need to put everything inside classes to the point where if they need to do an addition, they...

// do something like this:
class Operations {
    static add(a, b) {
        return a + b;
    }
}

// Instead of just:
const add = (a, b) => a + b;

But long story short, I would recommend to change the wording of this kind of articles a little to make them look more like "opinion/suggestions", and less like "facts/rules", so we avoid confusing juniors that might think this are like "universal rules" when they aren't.

Cheers!

Well, what about number | null cases? Let's say you're checking pizza price in an app and for an unknown reason, backend cannot find a value for the price and sends null, how would we eliminate null in this case? What would backend then have to send to the frontend if not a null? 0? :)

Imho work with user as class seems a little bit wierd. Behind of optional chaning usability is the outer data structure deep checking with sort code, I did not means as hack.

if (typeof user.functionDefinedOrNot === 'function') {
  user.functionDefinedOrNot();
}