If the document is frequently updated, you may assume it is part of the working set residing in RAM. So as read is concerned, it is better to have it in the same document, otherwise the working set is bigger, since you now have 2 documents, with indexes, …, for the entity.
However, if it is very frequently update, it might be helpful to separate it. As I have learned recently, a document is completely written when it is updated. So it might be better to have it in a smaller dedicated document. I italicized might because performance is seldom intuitive. There are so many factors, that testing is always best.
That is why, it is better to make it work correctly and then fix performance problem, if any, after.
Something that might, yes in italic, help, is to have a change stream to monitor this value. This way you do not need to read it because you just have it.
If a document is frequently updated it will remain in your working set residing in RAM (as mentioned by @steevej) and will be fast to retrieve. Separating into two documents means there is at least one additional index to maintain (since every collection has an _id index) and probably at least two indexes since you would want a unique index on user_id (although you could save an index by using user_id as the _id value for a count collection).
I assume your actual documents have many more fields which should be taken into consideration.
I recommend reviewing information on schema design patterns to see which may apply to your use case:
Bloated Documents – Separate frequently used data from infrequently used data in different collections to optimize your performance.
There are many factors that go into performance, so I recommend testing and tuning with your use case in a representative environment with some generated data to compare with expected growth. There are tools like mgeneratejs that can be helpful for mocking scenarios including extending based on existing data.