The note about flattening/unflattening is important because it indicates that the LabVIEW Type Cast does not always reinterpret data in-place. Depending on the type of data, it may copy data to a temporary buffer as a string, then convert that string to the new desired data type. This copying can be a substantial amount of time for a large array, particularly on a resource-limited device like a RIO (I've run into this, sadly, in trying to take a string received over TCP and push it to a FPGA through a DMA FIFO as an array of U32 or U64).
Well, that depends on which well you're referring to, and how well that well perform its water gathering function.
(case in point)
Actually flatten and unflatten are specifically inspired by the actual operation these functions do for non trivial and non scalar data.
And array of strings is in fact a memory area with one pointer for each string that points to another memory area somewhere to store the string contents. So the data structure is highly unflattended in memory with various memory areas all over the place containing the information that make up the data.
Flatten takes all these memory areas and copies them into a single contiguous memory block in the logical order of the data. Unflatten does accordingly the opposite by interpreting the data in a single memory block according to a datatype definition and reconstructing the data in memory as the original non-contigouos collection of data.
And yes for anything but scalars, clusters only containing scalars or simple arrays of scalars, flatten and unflatten can simply not operate in place, since the source and destination are then always in a highly incompatible memory layout.