Consider the possibility that you order two laptops from your favourite computer store. When you order them, you customise one, then in the shopping cart you hit "+1" to order two of them, so for the purposes of this example they are functionally equivalent. When they arrive though, they have different serial numbers ABC, and XYZ. So then we start asking the question, are they equal?
One way of asking this question is "Do these two things perform the same function?" to which we can answer yes, ABC and XYZ perform the same function - this line of questioning treats the laptops as ValueObjects as described in the article - laptop ABC and laptop XYZ can be swapped for each other without concern about whether they will behave differently.
Another way of asking this question is what amounts to something closer to "Is this thing the one that I care about?". This line of questioning treats the laptops as ReferenceObjects. You've just received both laptops, taken them both out of the box, they're functionally identical except that you've decided that you want to use ABC for work stuff, and XYZ for personal stuff, and now you have some work stuff to do. You pick up one laptop and ask "Is this laptop ABC?" - not because the function of the laptops matter at this point, but now because of what they represent.
Both have their pros and cons (as described, ValueObjects are better when they are immutable, ReferenceObjects might tend to be more complex), and different languages make different choices about whether certain language primitives and standard objects/classes are implemented as ValueObjects or ReferenceObjects, but understanding them both conceptually allows you to write code that forces one kind of behaviour because that's what matters most for your chosen solution, independently of what the language you are writing it in has as its standard behaviour.