That is my private branch, you should use default branch, no-one but me should use my dev branch.
I do work only in my private dev branch and I merge changes to default when I believe they are stable. Many changes are small and I believe they are stable right away so I merge them right away to default. Only when I have some work in progress that is unfinished or not tested then I wait until I'm finished before merging. It keeps it more simple to manage if changes I make are kept synchronized as soon as possible with the default branch. I don't like to accumulate a lot of changes in my dev branch for a long time and then merge a lot of changes all at once, my development and release cycles are very short and prgress happens very fast.
If you find a bug in default branch and I can validate it, it is usually fixed within hours if not minutes from when I can verify it.
I think yes, it is good for any developer with commit access to work in their own branch but the longer they go without keeping their branch synchronized it may get more difficult to manage merges especially if the devs are working on some of the same code and coding in different directions from one another. The more devleopers involved the more formal processes and planning need to be. With only a few developers it can be less formal and more nimble. Sometimes more developers actually slows progress down because of the need for more formal processes. Changes merged to default from individual developer branches also need to be merged to the other developer branches from default so that the only differences in any developer branch is what the developer is working on.
In some cases it might be useful to have additional branches for working on something experimental or proof of concept or some really major change in architecture that may not get merged for a long time if ever.
I'm sure lots of people have different ways and styles of working with source code management, this is just what I do.