vamos por dúvidas:

como isso ficaria misturado?

Vou usar esse exemplo javascript para demonstrar

Bad pratice

function makeBooking(cargo, voyage) {
    // Lógica de negócios e implementação misturadas
    let maxBooking = voyage.capacity * 1.1;
    if ((voyage.bookedCargoSize + cargo.size) > maxBooking)
        return -1;

    let confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cargo, confirmation);
    return confirmation;
}

Neste exemplo ocorre a mistura da lógica de implementação e da lógica de negócio, o que dificultaria cada parte do código de ser testado. Ao mesmo tempo que fere o principio do S.O.L.I.D que é explicado nesse vídeo do Deschamps.

Outro problema é que provavelmente você queira usar este trecho do código em outras partes do código mas com ele hard-code fica dificil.

Do outro lado temos este código seguindo a good pratice

class OverbookingPolicy {
    constructor(overbookingRate) {
        this.overbookingRate = overbookingRate;
    }

    isAllowed(cargo, voyage) {
        let maxBooking = voyage.capacity * this.overbookingRate;
        return ((voyage.bookedCargoSize + cargo.size) <= maxBooking);
    }
}

function makeBooking(cargo, voyage, policy) {
    if (!policy.isAllowed(cargo, voyage))
        return -1;

    let confirmation = orderConfirmationSequence.next();
    voyage.addCargo(cargo, confirmation);
    return confirmation;
}

Este código já automaticamente deixa o código menor, mais testável e mais reusável que o anterior já que eu consigo reutilizar a classe em outros pontos.

---

Que regras de legibilidades são essas?

Essas regras são o que chamamos de Clean Code baseado num livro de mesmo nome.

Essas regras de legibilidade tentam tornar o código mais simples de entender para outros programadores, normalmente quando você está escrevendo o seu código tudo parece muito mais fácil de entender do que quando um terceiro vai tentar ler ou mesmo você no futuro.

E acredite, clean code não é a única regra de legibilidade. Existe o D.R.Y que é sigla para Don't repeat Yourself, K.I.S.S que é sigla para Keep It Simple Stupid, Y.A.G.N.I que é sigla para You Ain't Gonna Need It, entre outros ... dependendo claro de projeto a projeto.

Bad Pratice

function clc(a, b, c, d) {
    var res = a * b + c - d;
    return res;
}

var r = clc(2, 3, 4, 1);
console.log(r);

Good Pratice

function calculateResult(multiplier, multiplicand, addend, subtrahend) {
    var result = (multiplier * multiplicand) + addend - subtrahend;
    return result;
}

var finalResult = calculateResult(2, 3, 4, 1);
console.log(finalResult);

e porque separar numa classe essa política? sendo que não está sendo utilizada em nenhum outro lugar?

Quanto se separa uma classe em uma política (no caso de strategy), você aumenta a testabilidade do código e começa a seguir um principio chamado príncipio de responsábilidade única. Ao mesmo tempo que encapsula sua lógica fazendo com que a lógica de negócio fique independente da lógica de implementação.

se tiver um bug no makeBooking, como separar essa política vai ajudar a encontrar o bug? acredito que testes já resolveriam isso.

Você está correto na parte do que testes já resolveriam isso, mas separar a lógica ainda ajuda no quesito de que você simplifica a refatoração e aumenta a testabilidade independente de cada um dos componentes