How so? cl_float3 is only created as a convenience type. Except for a lack of a w channel in a kernel, it is exactly the same as cl_float4.
But addressing to .w in cl_float3 must be a error.
Addressing to w needn't give an error, really. What is important is that if you pass float3 to function calls they behave correctly. For example, a dot product on a float3 is not the same as a dot product on a float4. If w is initialised to 0 this isn't really a problem barring marginally inefficient code generation. As long as once the data is on the device it is treated as a true float3, having the host cost correctly deal with the alignment characteristics is the most important thing, surely?
How else would you deal with it? Create a host structure containing x, y, z, _padding? Or just have x, y, z and hope compiler alignment guarantees are effective (which is something I don't have much faith in).
In a kernel it must be an error, not in the host program, as the spec only defines the kernel language definition. From the spec:
pos.z = 1.0f; // is legal
pos.w = 1.0f; // is illegal"
This only is illegal for a float3, not a cl_float3.
On a side note, the header file that defines cl_float3 is straight from Khronos, not something that we create. So if it is behavior you want changed, you need to go through Khronos to get it changed.