1. Zero cost.
There is no cost for using the CloudFormation template to provision resources. On the other hand, if the resources are provisioned using boto3 in lambda, execution does cost money. Even if the price is negligible, every penny helps.
2. Scaleability.
If the resource provision takes more than 15 minutes, it is impossible to provide the resource using lambda directly. In provisioning large resources with heavy bootstrap installations, it could be possible to hit those limits.
3. Fail-Safe.
When the resource provision fails for any reason, lambda doesn't take responsibility to clean up the resources instantiated so far unless it is handled explicitly. On the other hand, CloudFormation Stack does a clean rollback by reverting to the initial state. It does save money if the resources are cleaned up appropriately.
4. Less error-prone.
There is only one way (declarative using JSON or YAML) to express the intent in the CloudFormation template, and it is validated when creating the stack. On the other hand, when expressing it in a programmatic way, unless it is supported by high-quality tests, it may be error-prone. Also, CloudFormation guarantees that only provisioning of resources happens, on the other hand, boto3 opens up all AWS APIs and it puts the onus on developers to behave properly (Say, no accident deletion of S3 folder happens). An analogy is that writing in SQL is less error-prone than expressing it in any imperative language such as Java or .NET.
5. Maintainability.
The CloudFormation template is the standard IaC for AWS. Anyone who worked on the CloudFormation template can easily understand and maintain it. It's easy to compare different versions for any changes, as the structure is pretty much fixed. It's immune to breaking API changes, as it is declarative.
6. Drift detection.
CloudFormation stacks have the ability to detect any manual changes in certain resources. No such monitoring ability is possible with lambda provisioning, as it is a fire and forget operation.