I’ve seen others on the forum use this same saying about other things as well…in this case, no it is not. It is more like using a nail gun instead of a hammer, where the nail gun is good to use for all situations, and in those where there are a lot of nails it performs infinitely better than that of a hammer.
No, one reason to do it before you have the skill to do so is to build the skill to do so…you don’t have experience until you have experience. Plus, the error checker in the API connector will alert you to issues when you initialize, and in the logs you will see the error for failed workflows when you run the API call and there is an issue with the setup. Additionally, if using a plugin for JSON the issue checker will alert you to issues and the debugger will alert you to issues as well, just like any other built in functionality from Bubble (API connector) or well built plugin.
So as not to have to pay for WUs when it is not necessary.
You can do this with storing data locally as well, however, local storage is not lost when the user closes the browser or refreshes, while custom states are…so a good UX would utilize local storage instead of custom states so as to anticipate the potential a user may have computer crash or something else and when they open the app again, you can have them start where they left off, but custom states requires the user to start all over again.
Also, local storage allows data to be passed from page to page while custom states do not.
Having to think critically is not necessarily mental gymnastics, and in this situation it is not mental gymnastics. Most of the time people on the forum use the phrase mental gymnastics in reference to WUs is in the attempt to understand the costs of things, but not really in attempts to build optimally with WUs in mind.
In the case of the OP request for help regarding creating entries in database from cells in a repeating group, using the approach of JSON and API connector, in some situations may not lead to saving a few WUs. For example, I have a client app, that gets 70,000 - 100,000 visits per month from Google. They have a form to request a quote. That form allows a user to create multiple ‘loads’ in a repeating group, the number of loads is unknown, and so they can create as many as they want, delete them and modify them all without ever touching the database until they are ready to submit their request.
If I didn’t use the JSON and API connector, the client app would have potentially users creating and deleting things in large numbers before the client app could ever potentially monetize that user.
Now, consider a simple scenario, each user creates two entries in RG…if we create each individually in the database, that is two actions of create a new thing, and the creation of a new thing, which is 2.2 WUs plus the cost of characters…for api it is 1.75 WUs…if we think 100,000 users a month, that is 45,000 WUs per month, assuming each user only ever creates two things. Its not a few WUs, and in the end, every little bit matters.
Additionally, it is not just about WUs, its about performance.
At the end of the day, I’m just offering free advice on how to build the OP feature in an optimized way. If others do not want to build optimally, that is there choice.