PostgreSQL UPSERT issue with NOT NULL columns
Your second example never makes sense, while column1 is defined NOT NULL. You must provide a value for the required column, or the command will fail before it can even check for unique violations.
Query 1
This query only executes the UPDATE part only if either column1 or column2 are NULL and at least one actually changes (anything actually changes), but it does not allow to revert either back to NULL:
INSERT INTO test AS t
       (column1, column2          , status, id) 
VALUES (now()  , gen_random_uuid(), 0     , '5beb004a-63ec-4f01-8604-37296a208e5f')
ON     CONFLICT ON CONSTRAINT upsert_conflict
DO     UPDATE
SET    column1 = COALESCE(t.column1, EXCLUDED.column1)
     , column2 = COALESCE(t.column2, EXCLUDED.column2)
WHERE (t.column1 IS NULL
    OR t.column2 IS NULL)
AND   (t.column1 IS DISTINCT FROM COALESCE(t.column1, EXCLUDED.column1)
    OR t.column2 IS DISTINCT FROM COALESCE(t.column2, EXCLUDED.column2));

But COALESCE() never kicks in for this particular setup. column1, being defined NOT NULL, cannot be NULL, neither in the table nor in the input VALUES. So column2 has to be NULL or nothing happens. Hence we can never reset column2 to NULL anyway.
Query 2
This query only executes the UPDATE part only if either column1 or column2 are NULL and at least one is actually being changed -even if back to NULL:
INSERT INTO test AS t
       (column1, column2, status, id) 
VALUES (now()  , NULL   , 0     , '5beb004a-63ec-4f01-8604-37296a208e5f')
ON     CONFLICT ON CONSTRAINT upsert_conflict
DO     UPDATE
SET    column1 = EXCLUDED.column1
     , column2 = EXCLUDED.column2
WHERE (t.column1 IS NULL
    OR t.column2 IS NULL)
AND   (t.column1 IS DISTINCT FROM EXCLUDED.column1
    OR t.column2 IS DISTINCT FROM EXCLUDED.column2);

This time, actual input values are used, even if NULL. No COALESCE() that defaults to the existing value if the new one is NULL
db&lt;&gt;fiddle here
Either way, you can be sure that a row with (status, id) = (0, '5beb004a-63ec-4f01-8604-37296a208e5f') exists after executing the command successfully - even if that row might be missing from the set returned by a RETURNING clause. See:
Related:

How to use RETURNING with ON CONFLICT in PostgreSQL?