This advice seems a bit too simplistic, and I think misguided at least for the specific example of null values. I only know the details here for Postgres, so I'm not sure if this is valid for other databases.

In Postgres each null value in a column only occupies one bit (with some more complexity due to padding), so unless you have a very, very large number of columns that are mostly empty the space used by null values is negligible.

But one part of the idea I agree with, and that is that it can be useful to keep in mind how wide your tables are. If you're not doing index-only queries the database has to fetch all or most of that data (again, more complex in Postgres for TOAST columns). So if you have a wide table with non-TOAST columns, simple looking queries that only fetch one column might have to do a lot more IO compared to a less wide version of such a table.

I would not necessarily split table just as an optimization, but it helps a bit to think about how the tables will be used when designing the schema. There might be data in the same table that is used or updated in very different patterns, and that might be better handled by separate tables.