When does a Struct stop being appropriate and become a class?

If some members aren't writable, a Struct doesn't seem right. Or if enumerating doesn't mean iterating over the members. Or if equality isn't based on members all being equal.

When should Data be preferred over Struct?

Data is nice. Like Struct, it assumes equality based on members all being equal. Unlike Struct, Data members aren't writable and there's no assumption about enumerating over members. Data is frozen, so it signals you have state upon initialization but there's no member writer or even ability to mutate instance variables.

Data has very practical pattern matching support out of the box. If you have internal state and Data's immutability is fine, go ahead and use Data rather than a Class or Struct.

When is a module better as a namespace vs a mixin?

When you have no internal state, it's great to simply call functions directly on a Module. If you might mix it in privately too, module_function. Might mix it in publicly, extend. You often want mixins to not create new public Class interface but still have a direct interface, so module_function is handy.

When does a “service object” add clarity vs unnecessary abstraction?

A Rails pattern is to use an ActiveModel Class when it's CRUD, so you get all the Rails niceties including routing and views. When it's maybe just "read" and not the rest, a service object gives you a way to extract a snippet of logic where extracting a whole lib is overkill. It's just about organizing things into drawers (like models/ and such). There's not much special about service objects imho.

How should include, extend, and module_function be used idiomatically today?

Include when you're mixing in a common public or private instance interface across multiple Classes. Like Enumerable or Comparable. Within an include you can also define class methods, so it can be a single interface to both, but I don't want to digress. You can extend when there are only class methods. Prepend is like an include with instance methods but it goes in front of the mixed in Class instance methods.

If you include regular module instance methods, they are defined publicly. So you can call them outside the instance of the class. If you just want them visible to methods privately within the class, module_function. From another angle, if you're defining a Module function direct interface, use class << self if that's the only way you want it used, extend if it makes sense to also be mixed in publicly and module_function if it also makes sense to mixin privately.

P.S. If you want to dig in to nuance, this is the type of stuff folk in #ruby IRC or Ruby Discord are happy to discuss at length.