I would encourage your project manager to read some of the relevant forum discussions and review some of the design patterns and anti-patterns that apply to your use case. You have comments from community members with years of experience in MongoDB including supporting some of the largest production deployments .
If you think this data belongs together and should be committed in a transaction but you want to avoid multi-document transactions, that seems strong motivation to embed in a single document. However, I’m sure the actual use case is more complicated than optimising a single view counter so I would be very cautious about extrapolating comments on a single aspect of your use case to an overall recommendation. There are also practical considerations like resource usage for varying workloads that will be easier to predict by testing and monitoring in a representative environment.
If your project manager needs something more definitive or holistic than community discussion, it may be more appropriate to invest in professional consulting.
The path of least resistance would be to choose the approach recommended by your project manager (which I assume would be based on their MongoDB experience) and refine this later if it leads to performance issues.
Ultimately the correct approach to data modelling is informed by factors including how your application uses data, available resources in your deployment environment, and sensitivity to cost & efficient resource usage.