Unfortunately, this is a very common question that is asked when modeling data, which means there are few methodologies that various DBA's have to approach such a problem without any real solid, "yes" or "no" answer.
I would say that if you intend to have an OLTP database that is maintained by an application, then moving towards a normalized approach is likely going to be your best option. Then if you plan to have an analyzation component for BI purposes, then having a separate OLAP database where denormalization is likely going to be the best approach. This means instead of splitting the table up, keep the table as one single entity. This is mainly because splitting the data up will make queries of that table more complicated as well add additional overhead to querying that table as it now requires a JOIN. You will also likely see management of the secondary table more difficult when you do decide to mass update it in the future as well.
When it comes to allowing or not allowing NULL's regardless of the above approach, I should mention that while I personally have no real issue with it, the problem is NULL's are too vague in the specific sense. This means, allowing NULL's can mean anything to the end user whether they are human or not. You have no idea if the NULL is in result of value being unknown or the application has yet to write the unknown value or that an error has occurred.
To give a good example, I left NULL values in our log level data for BI purposes in the underlying fact table. The approach here was to take another field on the same record and use a string splitter to parse out a string of data that was delimited by underscores. In one position of the string, end users on the front-end would label it either _B_ or _NB_ as part of that string. In some cases, the position of these values would change, then the value would become NULL and thus give the illusion the front-end users did not flag the data when in fact, it could just mean the position of the flag is off or maybe there was an error in splitting the data correctly or something else entirely. Therefore, retaining the NULL here is likely not the best approach to ensure the end user understands what the TRUE meaning of the value is. I should have taken better care of translating the values in order to ensure the best insights when the data is finally utilized by whomever.