Yes, as @ptrblck said, these are the coordinate transformation, and the * is just Python to separate a tuple (returned by GetOrigin/GetSpacing) into separate arguments.
The easiest way to look at the transformation is irc2xyz (i.e. voxel indices to physical coordinates in the patient):
The key here is
coords_xyz = (direction_a @ (cri_a * vxSize_a)) + origin_a

And so starting out with the pixel indices cri_a:

The triple vx_Size_a is the size fo a single voxel, i.e. two voxels are exactly that many mm apart.
So cri_a * vxSize_a has a coordinates of the right size.
The matrix direction_a is an affine transformation, typically a orthogonal one, it typically be the identity or a mirroring of the coordingates (-1 on the diagonal) or a rotation (e.g., but not necessarily by 90° to exchange some axes). After this, you have a coordinate system that the directions of figure 10.6.
The origin moves where 0 is. I’m never 100% sure where it should be, but the software of the ct scanner gives it to us and we need it to match against the physical coordinates in the pixels.
Then you have patient coordinates. These are used e.g. for the annotations.

The other direction is the algebraic inverse of this.
This can be more than just a bit messy but so not all patients lie perfectly axis-parallel in the thing and so you have all sorts of weird effects. It is a wonder that we even get a common file format for all these machines across the world.
(And I’ve personally sat next to Luca when we converted some even more arcane format in some other project, so the LUNA dataset is actually quite moderate.)
Best regards
Thomas
P.S.: As an anecdote: Actually you can get by with only two very simple matrices for the direction in the LUNA dataset and we had the transformations hardcoded at first, but then we thought it might be better to code this up in general to let you use it with other data if you want (also more maths less magic  ).