Andrej's answer is correct. In the microflow that is used for a calculated attribute, you shouldn't change any attributes or make any changes that impact the user interface (even if the Modeler allowed you to, these are not things you would want to do in this microflow). In order to understand why, a bit of background info may be helpful.
Calculated attributes are (re)calculated every time an object that contains a calculated attribute is retrieved from the database. As an example, lets say you have the following:
If you retrieve 20 Orders on a single page, your calculated attribute will incur the cost to retrieve 60 OrderItems from the database and totaling the Price of each. If you have multiple users doing retrieves like this, or if you have users retrieving more than 20 Orders, you can see how your app is incurring significant processing cost to calculate totals for Orders that may not have changed since the last calculation took place.
In this scenario, you would want to calculate the OrderTotalPrice when the value changes, and only when the value changes. This will minimize your processing cost and result in better performance for your application. OrderTotalPrice will change when an OrderItem is added or removed from an order, and when the quantity or price of and OrderItem is changed. Event Handlers on OrderItem will capture all of these situations - I would use After Commit and After Delete event handlers for this, others may choose different event handlers.
Now back to your original question - you would want to change other attributes when changes are made in your app that will impact the value of those attributes. In the scenario above, changing other attributes in the calculated attribute microflow would lead to even higher processing costs and more significant impacts on app performance.
All of this is a long way of saying that, in my experience, calculated attributes should be used very carefully in Mendix apps. In fact, if you find calculated attributes on any of the entities in an app with a large number of objects, chances are good that those should be removed. My rule of thumb is: calculation should happen when, and only when, a change in the data warrants it.
Hope that helps,
I think microflows that are used as source for virtual attributes are subject to similar constraints as rules, namely: