I would argue that fields are cheap. I wouldn’t have any qualms about a user creating a personal field - say a “Priority” field with a rating.
If I, Jeremy, am a Designer in your system, and I have a personal view, “Jeremy’s Working View”, I can create a new field in that view, called, say, “JMO Priority Rating”.
That field should, as far as I can tell, be hidden in all other views, since it was not created in those views. (There may be an exception for views that currently do not hide any fields, as perhaps the underlying assumption is that a view not hiding any fields should continue to not hide any fields, even if those fields are made in other views). And if it ends up not being hidden by default in other views, that can be remedied with little effort. The field won’t affect any other views (in terms of sorting, filtering, grouping, etc) unless somebody manually chooses to have that field affect the view. Everyone else can happily go on using Airtable as normal, while completely ignoring my “JMO Priority Rating” field.
It seems very unlikely you’d have any issues with hitting the 500 fields/table limit, even when allowing for all these personal fields.
That would be my 2-cents… but perhaps you have other good reasons for not wanting people to create more fields?
It’s also worth noting that Airtable is pretty easy to experiment with. It’s usually pretty simple to undo what you just did in a non-destructive manner. And if that scares you, it’s trivially easy to make an exact replica (copy) of your base to test something out in.
