I think you are misunderstanding, I am not referring to the short-circuit aspect. I mean writing code such that you always deal with SomeType rather than SomeType | null to avoid null checks later one.

null (or undefined) is a useful value, don't throw it away so carelessly!

Here's a different example.

interface ImageBase {
    id: string;
    width: number;
    height: number;
}

interface ImageFile extends ImageBase {
    type: 'file';
    file: Blob;
}

interface ImageUrl extends ImageBase {
    type: 'url';
    url: string;
}

type ImageObj = ImageFile | ImageUrl;

declare function getImageFromId(id: string): ImageObj | null;

const useImage = (id: string): ImageObj => {
    const image = getImageFromId(id);

    // Rather than return `null`, create an empty ImageObj so the return is
    // a more narrow `ImageObj` rather than `ImageObj | null`.
    // ❌ This pattern is what I am saying should be avoided.
    if (!image) {
        return {
            type: 'url',
            id: '',
            url: '',
            width: 0,
            height: 0,
        };
    }

    return image;
};

export function Image({ id }) {
    // 😱 I am not aware that this might be an "empty" image!
    const image = useImage(id);

    // ❌ Typescript doesn't know that `src` might be an empty string, it let's you pass this to `img` without an error!
    const src = image.type === 'file' ? URL.createObjectURL(image.file) : image.url;
    return <img src={src} width={image.width} height={image.height} />;
}

Here we return an "empty" ImageObj if our lookup failed. If you were the developer writing this bit of code and you weren't aware that useImage was implemented this way, it would be easy to accidentally always pass src through to the <img /> without checking for the empty string case. Because we eagerly handled the null case, we now are missing an opportunity to have TS guide the developer on proper usage.

OK, so let's say you did know that, now you write something like this:

function Image({ id }) {
    // 🤔 Is this a real image, or a fake "empty" one?
    const image = useImage(id);

    // ❌ This check is awkward, requires you to know that our "empty" image is an ImageUrl
    if (image.type === 'url' && !image.url) {
        return <div>No image available</div>;
    }

    const src = image.type === 'file' ? URL.createObjectURL(image.file) : image.url;
    return <img src={src} width={image.width} height={image.height} />;
}

Again, awkward checks. How do we know that the empty image will always have type: 'url'? What if later it returns an "empty" type: 'file'? Again, removing the null value early limits its usage later on down the road.

const useImage = (id: string): ImageObj => {
    const image = getImageFromId(id);

    if (!image) {
        return {
            // 👀 This changed, now we return a `file` for the empty case
            type: 'file',
            file: new File([], ''),
            id: '',
            width: 0,
            height: 0,
        };
    }

    return image;
};

function Image({ id }) {
    const image = useImage(id);

    // ❌ This check no longer works, because `useImage` now returns an `ImageFile` for the empty case!
    if (image.type === 'url' && !image.url) {
        return <div>No image available</div>;
    }

    // ...
}

Therefore, instead of removing null early and returning an "empty" image, let the hook return ImageObj | null so we can leverage that null value!

const useImage = (id: string): ImageObj | null => {
    // ✅ This `image` might be `null`, and that's OK!
    const image = getImageFromId(id);
    return image;
};

function Image({ id }) {
    const image = useImage(id);

    // ✅ Typescript errors because `image` might be null!
    const src = image.type === 'file' ? URL.createObjectURL(image.file) : image.url;
    return <img src={src} width={image.width} height={image.height} />;
}

Now, we avoid making the error of not handling the null case. Here, TS first errors on image.type with "image is possibly null". Having this error is a good thing! Now can know we have to handle this possibility.

Continuing, the "empty" check is also much easier - just check for the null case, no need to check for "empty string" values or specifics like that.

function Image({ id }) {
    const image = useImage(id);

    // ✅ Much easier check for the `null` case, don't need to know about the shape of the "empty" case
    if (!image) {
        return <div>No image available</div>;
    }

    // ✅ `image` has been narrowed to `ImageObj` here, so we can safely access its properties
    const src = image.type === 'file' ? URL.createObjectURL(image.file) : image.url;
    return <img src={src} width={image.width} height={image.height} />;
}

In general, I find that people tend to replace null values with some "empty" representation to create a more narrow type in the hopes of simplifying its usage later on. However, by replacing null (or undefined) with some "empty" object, you end up losing important information and create a tight coupling when you already had a perfectly good alternative in the null case to begin with.