Building on what jis said about read-once properties such as CloudDB.Token, I ran a quick grep for @SimpleProperty(userVisible = false) across the runtime source to see how many fall into that category versus how many could be promoted.
After deduping getter and setter pairs, the count comes to about 97 unique declarations in 37 files (lower than the docs total because base-class properties such as ButtonBase.Shape appear once in source but under every subclass in the reference pages). Form.java alone holds 21 of those.
About two dozen are packaging or project-properties metadata that the build server or OS consumes before the runtime starts. Form.AppName, Form.Icon, Form.VersionCode, the Form.NS*UsageDescription strings, and WebViewer.UsesCamera are in this group. A block-level setter would have nothing to mutate.
About 10 more are form and layout properties such as Form.Theme where runtime mutation has lifecycle caveats and would need a closer look.
About a dozen are LEGO sensor port and motor wiring properties such as LegoMindstormsEv3Sensor.SensorPort and Ev3Motors.MotorPorts, which are more about device binding than ordinary widget state.
About 20 more are service and data config properties on CloudDB, FirebaseDB, DataCollection, and Spreadsheet. They vary from read-once values such as the one jis described to setters that actively reconfigure live connections, so they are not a uniform group.
The remaining roughly two dozen designer-only properties look like reasonable promotion candidates. They are properties on UI components such as ButtonBase.Shape, ButtonBase.TextAlignment, Label.FontBold, Label.HTMLFormat, TextBoxBase.FontBold, Spinner.TextAlignment, and ListView.FontTypeface. Each setter already mutates the view at runtime, so removing the flag would expose the existing code path to blocks.
These groupings are a first pass from source grep, so please correct me if I put any properties in the wrong bucket.
