It's not a big deal either way; helper methods vs. inline code is not a big deal and I'd be fine either way this goes.  

However:

>  My primary motivation in this branch was to take methods that were doing way to much, separate out logic, keep each step nice and functional, with one composing method that, thanks to the separation, reads like a description of the use case procedure. 

Moving all of that code into a single place (as this commit does) is the major contribution towards making ineligibility easier to understand.  Once that's done, though, I think

```ruby
def make_ineligible
  transaction do
    # Build an ineligibility record for the participant's person...
    SampledPersonsIneligibility.create_from_person!(@person)

    # ...destroy all their personal relationships, ...
    ParticipantPersonLink.where(:participant_id => participant.id).delete_all

    # ... links to their events (but not the events themselves), ...
    participant.events.destroy_all

    # etc
  end
end
```

is easier to read, because you don't have to learn any more new names.  Again, however, this is a matter of taste, and in the absence of any additional standards I'm fine with leaving the code as-is.

> I don't see the advantage of cramming these otherwise unrelated lines of logic into one method.

That's the thing: they _are_ related.  Although they affect different models, all of that code must be run to complete ineligibility.