You may disagree, but I believe it is a good practice to cluster all the SQL Server instances. That is, even when you plan to run a SQL Server instance on a single machine, you should install it in a single node cluster.
The primary advantage is that you only need a single standard SQL Server build instead of one for the stand alone and one for the clustered. This results in simplified configurations such as when you configure network aliases, Kerberos, and multiple instances.
If you need to add a second node later, that change will be totally transparent to your client. You may question how often one would need to add a second node. True, that may not happen very often. But when it does happen, you’d be thankful that you already have the cluster in place. Moreover, consider a DR scenario where you don’t want to have a two-node cluster doing nothing just in case there is a disaster. If it turns out that you do need to run your production on DR for an extended time period, you probably want to protect your production with a cluster. In that case, adding another node would be painless if your DR is already a single-node cluster.
When it comes to using network aliases, I strongly prefer to expose and manage all the network aliases of my SQL Server instances explicitly as network resources. Network resources introduce additional constraints that make the network aliases less fragile to mistakes and help reduce chaos when we need to move them among the hosts.
Kerberos configurations can sometimes be finicky and the procedures for a clustered instance and those for a stand-alone instance are different. Anything you can do to reduce the Kerberos configuration complexity is a plus for robustness of your environment.
When multiple instances are configured in a cluster, they must have separate IP addresses, and this makes it trivially easy to create network aliases for a named instance, completely eliminating the need to reference any two-part name on any client and making the ‘server location’ completely transparent to all the clients. By 100% server location transparency, I mean the ability to move a SQL Server instance to a different machine or a different cluster without changing any configuration at all on the client side. This offers huge convenience, and in many cases is an absolute necessity.
From my personal experience, I have not seen any serious downside to this approach. Hope that’s your experience as well. As always, I’d like to hear your different views/opinions on this.