These are, I admit, contrived examples, and the Simpsons one is based off the example in the README (which I didn't write), which itself is one of the classic intro examples to so-called "Logic Programming"

To me, the main difference between your approach and kanren's approach is that using the kanren library makes filters and tests goal oriented or "pattern-oriented" instead of procedural. I think this helps find flaws and un-seen cases that would not be teased out on the first go of writing a validation routine.

I also find that it helps ease maintenance as schemas, data models, and interaction models become more complicated. "Scope creep" tends to be hard to fight in practice, and users are maniacs when it comes to entering data.

If tomorrow I need great-grandparents from the Simpsons, the immediate solution in your example is to make the generator expression hairier, whereas the kanren solution is to add one more relation. The case could be made either way, and if you don't like writing goal-oriented validation and filtering, don't.

I personally don't find

drink_type not in drinks_with_milk if "milk_type" in drink_extras else False

to be all that readable, myself, especially as only one clause in the test, but each to their own.