It's easier in a monorepo to do the cross-subprojects changes.
Imagine the main product (for example a plugin for WordPress) and a bunch of subproducts (addons to that plugin). And you do a refactoring for the main product code, or changes in product require synced changes in subproducts. It's easier in this case to maintain everything - code, issues. Single commit will include all changes - review will be much easier (bigger diff, but easier to see it in the same place). Building artifacts is unified - you won't need to copy pretty much the same build tools/steps (using gulp or npm, for example) in every single repo for every subproduct.
So, imo, monorepo is good for tightly coupled directories of code, that doesn't really work without each other.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's easier in a monorepo to do the cross-subprojects changes.
Imagine the main product (for example a plugin for WordPress) and a bunch of subproducts (addons to that plugin). And you do a refactoring for the main product code, or changes in product require synced changes in subproducts. It's easier in this case to maintain everything - code, issues. Single commit will include all changes - review will be much easier (bigger diff, but easier to see it in the same place). Building artifacts is unified - you won't need to copy pretty much the same build tools/steps (using gulp or npm, for example) in every single repo for every subproduct.
So, imo, monorepo is good for tightly coupled directories of code, that doesn't really work without each other.