Not sure if there is 1 correct answer to this one.
Personally I started using a singleton factory (there are different ones out there) for the Safe, because we wanted to enable everyone to deploy the contracts to the same address (e.g. on a local network).
But this is not the only advantage. By using such a factory the contract address itself is proof the code (at least in most cases ... there are ways around it). Which makes it easy to verify that a contract is the same across networks, as you only have to compare addresses. Also when your contract is the implementation (formerly often called master-copy) contract for a Proxy contract setup, this also provides an additional layer of security as this contract could be redeployed in case of an unwanted selfdestruct (see Parity case).
In cases where you want more individual instance of your contract, instead of one singleton, I would say using the normal deployment flow, make more sense.
Note: The Singleton Factory relies on a presigned transaction that does NOT use replay protection. It is not possible to use this transaction on all networks, as some require replay protection (e.g. Avalanche and Optimism).
Edit (Follow up on "there are ways around it"):
The singleton factories use the create2
opcode to make the deployment as deterministic as possible. In this case the address of the new contract depends on the factory address, the deployment code and a salt.
It is important to understand how the deployment code is used. Normally the deployment code runs the constructor, loads the "runtime" code into memory and then returns the "runtime" code so that it is stored in the blockchain (here a nice blog post on this).
But it is possible to build the deployment code in a ways that it loads the code from another contract where the code could be stored in a variable that can be changed. Therefore the same deployment code would generate different runtime code. So the address would be the same but the code would differ.