Cloning the repo to the developer's local machine is already a kind of forking. If each developer forks the repo on GitHub, this only serves to publish their current state of work.
This can be appropriate when there is a central master repo, and many contributors that are not trusted with direct access to that repo. This works great for open-source projects where everyone can contribute and issue a pull request that is then reviewed and merged by a group of core maintainers. Using multiple repos enforces a pull-request based workflow.
In a small, trusted team, this is not necessary. To prevent different people getting in each others way, a strategy such as the Git Flow can be followed: Each small feature is implemented on a separate feature branch. When the feature is complete, it is merged into the master branch. Most teams will couple this with a pull request or code review by convention, but are trusted enough to skip that if appropriate. Whereas separate repos would lead to a developer publishing their current state on their forked but team-visible repos, in a single common repo they would push their changes to a separate feature branch. Doing all development on master/trunk is highly discouraged in most workflows.
The difference ends up being solely about access management, and not so much about the implemented workflow. You can do pull-request based workflows with either setup. From a raw Git perspective, there's not much difference between a fork and a branch – either approach essentially shares the history of the project and allows commits to be added without affecting other branches/forks. Considering this, it would be much better to share a single repo when in a trusted, closed group.