Why are ADT packages opened immediately after they are built, while existential objects opened as late as possible?
You can see an instance of the claimed property in the two definitions of add3.



In the ADT style, add3 is defined as:

let { Counter, counter } = counterADT in
let add3 = λ (c : Counter). counter.inc (counter.inc (counter.inc c)) in
counter.get (add3 counter.new);


As you see, in order to call about inc, one must already have opened the existential package. You cannot write the inc3 function in the "ambient scope", as Counter is not an ambient type, but a type encapsulated in the counterADT package.

You could repackage everything after the first call to inc, and re-open the package before the next call, but that would be somewhat pointless.



In the object style, add3 is defined as:

add3 = λ (c : Counter). sendinc (sendinc (sendinc c)))


Here, the client code does not open the existential package themselves.  Instead, each call to sendinc will open the package when it needs to run inc, and will repackage the output.  The client could just do the same, but that is not the intent of this style (they would be breaking the abstraction).



So, the confusion might be that you understood the sentence as "the packages are open at a given time", as opposed to "a programmer would be expected to open the package at a given time".



The difference in timing comes from the way we want to use these two mechanisms.  

The ADT mechanism is one where we have a single representation, that we wish to hide, while giving some actions to perform on that representation.  Because there is a single representation, it is perfectly acceptable to unpackage it once and for all.

The object mechanism is one where we want to potentially allow multiple representations that all share some actions to perform on them.  Because we want to allow multiple representations, each package should be responsible for knowing how to perform the abstract action on its concrete representation.  If we were to unpackage the existential type early, we would locally be restricted to a given representation.

This becomes very interesting when thinking about binary operations over the packaged type: in the ADT style, the two operands are guaranteed to share the same representation, whereas in the object style, each operand could have its own concrete representation and its own way of implementing the binary operation.

http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

^ This paper, "On Understanding Data Abstraction, Revisited", by William R. Cook gives a lengthy explanation of the difference in power between these two approaches, and is, in my opinion, an excellent read.