You have two options.

(1) You can enable the preview feature in Java 14, by compiling with

javac MainClass.java --enable-preview --release 14

and running with

java MainClass --enable-preview

(2) The line you wrote is equivalent to this.

if (this.areas.get(i) instanceof Habitat) {
    Habitat area = (Habitat) this.areas.get(i);

    // ... more here

Assuming, of course, that this get method doesn't have any nasty side-effects. This is how you do it if you don't want to enable the preview feature.

The way the quote explains why the second case does not compile is worded extremely strange, maybe even wrong. So here is my way of explaining it.

The way you have to look at pattern match variables is that they are only declared if they are assigned (in the spec they call this 'introducing' a pattern variable).

Let's look at an example:

if(myOb instanceof Integer iObj) {
    // ...
}

Now inside this if statement, the instanceof must have returned true, so iObj is 'introduced' and therefore declared. This means you can both read from it, and write to it (as it isn't a final variable, note that myOb instanceof final Integer iObj is valid Java).

Let's now jump to the first case given:

if((count < 100) && myOb instanceof Integer iObj) {
    // ...
}

So why does this work? The language designers made sure that if you have a statement in the form of:

if (exprA && exprB) {
  // ...
}

that it is equivalent to:

if (exprA) {
  if (exprB) {
    // ...
  }
}

This why you have short circuiting in Java and so many other languages. Doing this to the 1st case we get:

if (count < 100) {
  if (myOb instanceof Integer iObj) {
    // ...
  }
}

Because the inner if matches the first example I gave, it makes sense that again inside the if block the pattern variable must have been 'introduced' and is therefore assignable.

So why doesn't this work with & just like with &&? Well, because the language designers decided not to I suppose.

I do have an argument as to why they decided this. Given a statement like this:

if (exprA & exprB) {
  // ...
}

It is essentially the same as:

boolean tempA = exprA;
boolean tempB = exprB;
if (tempA && tempB) {
  // ...
}

And although we can split the && operator here again, it doesn't matter. In the case you gave, we would get boolean tempB = myOb instanceof Integer iObj. This statement can't 'introduce' a pattern variable because it could be that myOb wasn't an Integer which means that it can't guarantee that iObj would be assigned.

So even though 'myOb instanceof Integer iObj' in both cases must have returned true for the code in the if block to be run, because the language designers didn't make rules for how pattern variables get introduced by & like they did with &&, the 2nd case in the book won't compile like the first one.

So why can you use int iObj = ... in the if block with & but not with &&? Well, as we just saw with &, the compiler doesn't consider the pattern variable to be 'introduced' to the block, so you can define it inside, but with && that is illegal because the pattern variable IS introduced, which means you can't redeclare it.

This is a typical scenario where subtype polymorphism helps. Do the following

interface I {
  void do();
}

class A implements I { void do() { doA() } ... }
class B implements I { void do() { doB() } ... }
class C implements I { void do() { doC() } ... }

Then you can simply call do() on this.

If you are not free to change A, B, and C, you could apply the visitor pattern to achieve the same.