The current "requirements" is very difficult to understand, so I think it would be better to use a form like "effects".
Like this

reqs:
  - req: number
    number: attributeA
    more: 3
    less: 5
  - group: or
      - req: number
        number: variableA + attributeB
        value: 15
      - req: number
        number: variableB
        min: 5
  - group: and
      - req: wand
        target: source
        invert: true
        wands:
          - wand
      - req: light
        max: 5
        min: 3

if (
  (attributeA > 3 && attributeA < 5)
  && ((varA + attributeB == 15) || (varB >= 5))
  && (!wands.contains(wand) && (light <= 5 && light >= 3))
) {
}

do you realize that changing the way action performs will affect every spell ever made with it and likely break them all?

also, everything is possible if you are stubborn enough:

    - class: CheckRequirements
      requirements:
        - attributes:
          - attribute: attributeA
            min: 3
            max: 5
      actions:
        - class: ModifyAttribute
          attribute: summ1
          value: varA + attributeB
        - class: CheckRequirements
          requirements:
            - attributes:
              - attribute: summ1
                value: 15
          actions:
            - class: ModifyVariable
              variable: temp1
              value: 1
        - class: CheckRequirements
          requirements:
            - attributes:
              - attribute: varB
                min: 5
          actions:
            - class: ModifyVariable
              variable: temp2
              value: 1
        - class: Probability
          probability: temp1 + temp2
          actions:
             //i gave up on this point

Something like LogicalExpression action with "type" parameter (and,or,xor etc.)

Definitely not happening. But as a separate new action class - may be.

I'd actually support this change, even if I'd have to manually rewrite every single config to fit this format. It's much more understandable and logical.

I agree that the current requirements format has a steep learning curve. There are maybe ways some shorthands could be added while keeping the existing format for backwards-compatibility, but I would say this won't be high on my list of things to look at.

The suggested format I don't think is valid YAML though.