The question marks refer only to the gammaInput statement. This line is actually not necessary in this example since Texture.encoding determines how the texture is encoded and how the decoding should happen in the shader.
Basically yes, since these entities allow the correct usage of environment maps in context of physically based rendering. MeshStandardMaterial is based on a metalness/roughness workflow. In order to implement the concept of roughness correctly with environment maps, you need to do some preparation. PMREMGenerator creates multiple versions of the map based on different roughness values and also creates the corresponding mipmaps. PMREMCubeUVPacker just takes all these texture data and transforms them into a single texture for rendering (you can see this texture for debugging purposes on the floor of the example). While rendering, the fragment shader picks an appropriate version of the environment map based on the respective roughness value of the material.
Whenever you use MeshStandardMaterial, you should also use prefiltered mipmaped radiance environment maps.