The Social Security Number may be theoretical unique per natural person, but there are people without (e.g. foreign customers). And as in any systems there are "holes" where people got two numbers and they will be merged. Or two people got the same (because two John Smiths were born at the same day in a small town and maybe the parents are even neighbors) and this will be fixed later.
Besides of this the SSN falls under the data protection rules and now imagin, that you have used it in 100 sub tables as foreign key - a data protection nightmare, particularly when you have to change it.
And then the SSN is usually be saved as VARCHAR / CHAR(12) (very seldom as 8 byte BIGINT), while an customer_id will be usually a 4 byte INT (if you are not Facebook, Google or Microsoft it will be unlikely that you will have more tha 2.4 billion customers and even in this case you could restart with negative numbers to double the range or have enough money to switch to a BIGINT). Yes, disk space is cheap now, but SQL Server can much better join on as small INT than on a big VARCHAR. And RAM is for many SQL Servers still a rare good, many are limited to e.g. 128 GB because they run on Standard Edition.
Regarding "Use of parent and child tables" - Normalization is the absolute basic stuff regarding databases and should be done without mentioning it. But since your article is about speeding up queries - in this case normalization slows down your queries, because you have to do the lookup / join. For this reason data warehouses (DWH) will be often denormalized to speed up the queries.
Indexing: recommending to convert all names to upper cases to allow case insentive searches is a bad advice. MS SQL Server is per default case insensitive, so there is no need to do this. Furthermore it will often lead to something as "JOIN UPPER(p.name) = UPPER(o.name)" which is non-SARGable and forces a slow index scan instead of a fast index seek.
Partitioning: Yes, this can improve the performance by a lot, BUT the partition column MUST be included in any UNIQUE index (-> you can have two times the ID 1242 with two different creation_dates) AND you must include the partitioning column in any WHERE or JOIN on the table, otherwise the query will be slower than without the partitioning. And the creation_date is often a very bad partitioning column (because it is more or less random), contrary e.g. to a order_date. Of course a creation_date may be a good option too, e.g. for news, messages, posts etc. where you usually query only the last x days, but you have to know your datas and their common usage very well to plan this.
God is real, unless declared integer.