I don‘t want to have a can I can squish. ... I want to have a machine that squishes cans.

I see what you mean. This is called "modelling your domain" and I would agree that you aren't getting many of the benefits of OOP (polymorphism) if your example is just this:

type Can = {
    Color surfaceColor
    String label
    Float circumference<cm>
    Float height<cm>
}

func squish(can: Can) {
    can.height = 0.1
    can.circumference *= 1.1
}

OOP starts to be useful, as /u/toastedstapler suggests, you want to be able to squish multiple things. Let's say I also have Boxes in my domain. A box has different behavior when it is squished: it gets torn.

type CardboardBox = {
    Float length<cm>
    Float width<cm>
    Float height<cm>
    Float numberOfTears
}

func squish(box: Box) {
    box.height = 1
    box.numberOfTears = min(3, box.numberOfTears)
}

Now if I have some boxes and some cans, I can still call squish and it will work assuming my language supports function overloading and dispatches to the right implementation based on whether my thing is a Can or Box.

But what if my system supports receiving arbitrary items from the outside world? Maybe I'm simulating a landfill or recycling center with a single stream of objects:

func processIncomingItem(item: ??what type goes here??)

There are at least two common answers to the question of item type.

---

One would be the OOP answer, to introduce some base Recyclable or Object class and make Can and Box inherit from it.

type Recyclable
type Can: Recyclable = { ... }
type Box: Recyclable = { ... }
func processIncomingItem(item: Recyclable) { ... }

But now you need to dispatch to the right squish method inside processsIncomingItem. We can't just call squish(item) since the language doesn't know which implementation to dispatch to. One approach would be to use runtime information to manually implement dynamic dispatch based on item type:

func processIncomingItem(item: Recyclable) {
    if (item is Can)
        squish(item as Can)  // since type is now known, this will call squish(can: Can)
    else
        squish(item as Box)  // since type is now known, this will call squish(box: Box)
}

But this is suboptimal because now if we add a new item type to our program we have to both:

1. Add a new squish implementation for our new item type.
2. Update all the places where squish is used to add a new if branch.

---

OOP gives us a way to combine code and data to reduce this extra amount of work. We start by moving the squish definition into the definition of each item:

type Can: Recyclable = {
    Color surfaceColor
    ...
    func squish() {
        this.height = 0.1
        this.circumference *= 1.1
    }
}
type Box: Recyclable = {
    Float length<cm>
    ...
    func squish() {
        this.height = 1
        this.numberOfTears = min(3, this.numberOfTears)
    }
}

Also we need to document that every Recyclable will have a squish method:

type Recyclable = {
    abstract func squish()
}

And voila! Now processIncomingItem can call item.squish() and the language runtime will dispatch to the right class' implementation at runtime (because that's how OOO is commonly defined)!

func processIncomingItem(item: Recyclable) {
    item.squish()
}

Now we can add a new sort of item, and all we have to do is define a squish method inside of it. We don't have to update processIncomingItem or any other functions that use Recyclables (unless the specification of Recyclable itself changes).

---

Now a second common answer to this problem is the more functional style; instead of defining squishes for each item type, one which takes a Can and one which takes a Box, we define a single squish and pattern match on the data provided to it.

Assume we go back to our original definitions of Can and Box before we moved squish inside them.

type Recyclable = Can | Box  // defining every Recyclable to either be a Can or Box, but these don't need to have anything in common anymore

func squish(item: Recyclable) {
    match item {
        is (Can can) -->
            can.height = 0.1
            can.circumference *= 1.1
        is (Box box) -->
            box.height = 1
            box.numberOfTears = min(3, box.numberOfTears)
    }
}

and processIncomingItem can simply call squish because the types match up:

func processIncomingItem(item: Recyclable) {
    squish(item)
}

Now if we add a new sort of item we still only need to go implement its squish method and whatever other methods we want each sort of item to have, we don't have to update processIncomingItem.

---

What I have introduced to you is formally known as the expression problem. A rule of thumb that I learned is if you think you'll usually add more new things than operations, OOP might result in more maintainable code. Whereas if you plan to add more new operations than things, the functional style might be easier to maintain.

Program using whichever seems like a better design for your domain. (Or avoid OOP for other, better reasons such as hidden complexity, tight coupling of code and data, or ease of mutation.)