This is just a general Ruby/Rails tip, nothing specific to active_interaction (except that it demonstrates that it may be useful sometimes, and gives a specific example of when you might use it).

Still, in my opinion, this doesn't belong in the docs. Partly because I think repeating the default: nil for every item is an acceptable type of duplication, which would be better, clearer (because it's more explicit), simpler, keeps those details closer to the place where they are relevant (imagine if there were 50 fields within a with_options block).

I also think think that it creates a very arbitrary logical "grouping" within your code, which may cause you to unintentionally override/trump / miss the chance to use a different, more logical/natural/important/useful logical grouping instead. For example, it might be more natural/important/useful to group the fields by the section/fieldset/model that they belong with, even if your only grouping is a comment:

# User fields
string :name
integer :age
date :birthday, default: nil

# Food preferences
array :pizza_toppings
boolean :wants_cake, default: nil

may be a more useful grouping/organization than:

# Fields that are required
string :name
integer :age
array :pizza_toppings

# Fields that are optional
with_options default: nil do
  date :birthday
  boolean :wants_cake
end

Or it might be better to list them strictly in the same order as they appear in your model that you are trying to match. Why? Because then you (or your code reviewer) can more easily compare the lists between the two places to make sure you haven't missed any fields from the model, and quickly be able to identify which ones are missing (hopefully intentionally missing).

In other words, their "optionalness" seems to me like a pretty incidental property, not a key property worthy of allowing to dictate the organization/order/grouping of your code.

This definition may be a bit too broad. Others (like Reform) define it to have smaller scope — only the part where it persists/validates attributes. The other side effects might be better to put in a different location, like the controller action, or a service/processor object that has a form object.