You mix two very different things together here.
The first sentence is in fact a little outdated and only telling you half the truth although technically still correct.
Because you can pass LabVIEW native datatypes to DLLs since about LabVIEW 5 too. That is when they added the "Adapt to Datatype" to the Call Library Node and since then the CLN is in fact equivalent in this aspect to CINs.
So the sentence is right that CINs get the native data passed to it but forgets to mention that that is possible with CLNs too, and this sentence is in fact a remainder from the time when CLNs indeed did not have that option, due to system limitations in the at that time supported platforms including the Windows 3.1 and Mac OS Classic versions of LabVIEW.
The second talks about structures containing C array pointers which you can get sometimes when calling existing shared library APIs. Since LabVIEW does not represent arrays and strings as C pointers there is no simple way to create such structures in a LabVIEW diagram. But if you do create the DLL yourself, you are of course free to define the type of your function parameters and in such a way can use the LabVIEW native datatypes for your shared library function parameters by choosing Adapt to Type. This is an choice you do not have at all with CINs as they ALWAYS receive the parameters as native LabVIEW datatypes.
So it is not that CINs give you something you do not have with the CLN too, but that the CLN also allows you to call many API functions directly that use C array and string pointers as parameters. But this only works if the C pointers are directly function parameters, not when they are embedded inside clusters you pass to the API.
As last remark a handy trick when creating CLNs using the Adapt to Type feature or any of the LabVIEW native datatypes such as String and Array Handles:
1) Wire up the Call Library Node with the datatypes you want it to have
2) Right click on it and select "Create .c File"
3) In the file dialog select a file name to write to and LabVIEW will write a C prototype with all necessary parameter typedefs and the extcode.h include to disk so you can go on and copy/paste it into your C source code to be sure to start with the right prototype.