The errors are given because otherwise the client might try to access an inaccessible attribute and that would result in a run-time security error.
However, the Modeler security check that checks whether attribute access is allowed takes a lot of time (sometimes more than all of the other checks combined) and does not cover all cases, so I would love to get rid of it entirely. Internally we also came up with the idea to not render widgets if you do not have access. Now that we have input widgets with built-in labels, I think it would nicely if we just hide a text box if you do not have access to an attribute. The only thing is that you might be surprised that a widget or column is suddenly gone, but that might be a small price to pay.
So yes, good idea and I have good hope that we can do this in the near future!
The compilation error as you call it, can be circumvented by unchecking the check security box in the security settings. Be aware however that you'll need to take more care on setting the security without the help of checks by the modeler. Although you can now run the model, this setup will still require you to setup conditional visibility based on roles on the pages, else you'll get to see the errors for the fields referring to the permissions that will not allow to build the widget. So doesn't seem to be the greatest thing to setup in your model. I would agree that when permissions are not assigned the interpretation of the model could be to simply not render the widgets in stead of showing an error. Maybe the rationale is that the errors would provide a feedback mechanism that would otherwise not be possible. Also this checking forces the modeler to carefully think about security and enforce consistency. That being said I would also be able to live with the option that fields are not rendered if permissions on attributes are not set.