Using Grist as a primary datastore for a website/app will not by itself get you flagged/banned. Bad scenarios that lead to problems are when a creator makes a site/app, then leaves it unmonitored. Eventually something starts to give, and we need to take action. Actions we take include communicating with the owner of the document, or quarantining the document to limit its impact on others while continuing to provide service.
For how many records are too many - our best effort at answering this is Limits - Grist Help Center.
Writes to a Grist document are serialized. If two requests attempt to change one cell, then one request will be honored first, and then the other will overwrite it. Not sure if that answers your question - let me know if you have a different kind of conflict in mind.
There isn’t a specific TTL feature on records. If you were willing to do it manually, you could periodically filter records and delete them in bulk. That could also be automated via scripting. But I definitely see the value of an easy-to-use feature here.
As you found, individual Grist documents are stored as individual SQLite databases.
For pros and cons, I’d say Grist isn’t optimized for your use case (yet) so there’d be a lot to be said for a service tailored to you. Pay particular attention to our API limits Limits - Grist Help Center. If you have a busy site, api calls could start returning a “try again later” code to some users, which isn’t great. Also, our API also doesn’t yet offer authentication mechanisms tailored to user from a browser.