The answer is: it's not inherently a problem. JSON is fine for storing data that you access often. JSON is fine as a transfer system between services and apps.
The issue isn't with JSON. The issue is with
fs. So really, this applies not just to JSON but also to TXT files or any other plain text file you're attempting to write to.
See here's the thing: If you're attempting to simultaneously read a file and write to it at the same time, or if you're writing to a file from more than one location, the file risks being corrupted. And the more this happens, the higher the chances. It might work for small bots, but as it grows you are going to lose that data.
Not for all purposes. As we cover in Adding a Config File, you can store static data that generally is modified manually and applied on bot reboot. That data can be as big as you want - it can be just 4 keys, it can be 1000 entries in a random text thing... the fact is it's being loaded once and then not written to.
You have so many good alternatives to using JSON. And some are covered right here.
If you want a simple
key/value pair storage, like ID + Object, you can use
enmap, which is covered in Introducing Enhanced Maps.
If you need a little more umph, like multiple tables, multiple keys, etc, you can use
sqlite. The SQLite-Based Points System page shows you how to do a points system but of course, SQLite can be used for much more than this.
For more stable, multi-process access, think of getting a bigger database system. While those systems will require the installation of a database server, they will offer much more capabilities, power, and reliability.