I am sure standardization is nothing new to network engineers. After all, we rely on the TCP, UDP, ICMP, IP, and many other standards for our network nodes to communicate with each other. Standards give us a way to stand on common ground when comparing different elements. Think of a time you talked to your colleague about an OSI layer 3 technology to start the conversation, so your colleague could draw the right comparison in his or her mind. When we design networks, we know that a standardized topology using similar vendors and protocols helps us troubleshoot, maintain, and grow our network.
What is interesting is that as the network grows in size, so does non-standard configuration and one-off work. A single switch in a wiring closet will start to be daisy-chained when we run out of ports, our once standardized border access-list on devices no longer follows our number schema or preferred way of description when they starts to grow. Have you seen a snowflake under microscope? They are beautiful to look at, but each of them is different. A non-standard 'snowflake' network is probably one routing-loop away from causing an outage.

What is a good standardizing strategy? The truth always stands between a completely organic network and a single standardization. Only you can answer that question. However, over the years I have seen good results for having two or three standardized topologies separated by function, say, core, datacenter, and access. There are probably several non-flexible requirements depending on network functions, for example, the size of routing table in the core network. Therefore, starting with the network function and limit the standard as far as equipment, protocol, and topology generally yields good balance between the need for localization with standardization, in my opinion.