Primeiramente, não existe uma definição única, canônica, universalmente aceita e livre de controvérsias sobre o que é orientação a objeto. Recomendo a leitura do artigo Nobody Agrees On What Oo Is (Ninguém concorda sobre o que é Orientação a Objetos) para mais detalhes.

Na imagem acima, à esquerda temos Alan Kay, que é "só" o criador do termo "Orientação a Objeto". E à direita, Bjarne Stroustrup, criador do C++ e eu diria que ele sabe uma coisa ou outra de OOP :-)

Se nem esses caras concordam, não sou eu e nem você que vamos dar a "definição definitiva".

Não estou dizendo que você está errado, mas também não está 100% certo - ninguém está, vc leu o primeiro artigo que eu sugeri? :-)

É só pra dizer que o assunto é um pouquinho mais complicado do que parece. O problema é que os cursos acabam ensinando de uma forma muito simplificada, então isso aqui fica mais como uma provocação, para indicar que o que você disse é apenas a ponta do iceberg, e que existe um mundo bem mais complicado por trás.

Enfim, usar classes é uma das formas de se fazer, mas não é a única. Você pode usar prototipagem (o exemplo mais conhecido é JavaScript), e até mesmo em C é possível programar orientado a objeto (não é simples e nem prático, mas também não é impossível).

Isso porque, mais importante do que "como" fazer, é "o que" fazer. Apesar de todas as controvérsias, muitos "tendem a (geralmente) concordar ^{mais ou menos}" que existam 3 pilares fundamentais em OOP: encapsulamento, herança e polimorfismo. Usar classes é uma forma de conseguir isso (e se tornou popular por facilitar bastante isso), mas não é a única.

Por fim, de forma alguma estou criticando OOP. Ela é uma ferramenta como qualquer outra: tem prós e contras, casos em que faz mais sentido e outros nem tanto. O problema, como acontece com qualquer ferramenta, não é usar, e sim abusar, usar errado (ex: fazer código procedural usando classes) e/ou quando não é a melhor opção.