When someone explains what image tiling is in Vulkan they essentially refer to the layout of the image, and say that OPTIMAL tiling is laid out in such a way that it's efficient for the GPU to access, and LINEAR is, well I guess raw bytes as you'd expect, pixel for pixel. But this explanation is what I understand VkImageLayout to be. When you transfer an image to get the linear pixels you transition it to TRANSFER layout. When you need it to be accessed by the shader you have it in READ_OPTIMAL or SHADER_READ_OPTIMAL. I know tiling and layout are supposed to be two orthogonal concepts, but they seem the same to me given what I've just outlined.
Also, what are the use cases for tiling LINEAR?
To avoid circular use of terminology with what I'm trying to explain I use "memory arrangement" in this answer to mean some ordering of pixels (tiled, linear) and/or packing of bits in memory (compression, etc).
Image properties define persistent (and immutable once created) memory arrangement properties that apply to the image. Properties that can influence memory arrangement include the obvious ones (e.g. tiled or linear) but also things like usage flags (e.g. if STORAGE usage doesn't support framebuffer compression, on some implementations an image declared as being usable by STORAGE operations may always use an uncompressed memory arrangement).
Image layouts are further refinements to the memory arrangement that are allowed to be dynamic and stage usage aware. This allows more optimal (or more compatible) memory arrangements to be used for specific stage usage. For example, on some implementations the optimal memory arrangement for fragment shader framebuffer write is not the same as the optimal memory arrangement for compute shader imageStore() writes.
On most implementations image layout transitions are actually a no-op and don't do anything. On these implementations memory arrangement is decided entirely based on the image creation information (tiling and allowed usage flags), and doesn't change with layout transitions.
On other implementations, image layout transitions are usually a no-op, but are not always. For example, early AMD implementations could not use compressed framebuffers for imageLoad/Store(), so the layout transition for storage usage could trigger an implicit transfer to change the memory arrangement (apply decompression) so that the compute pass could access it. Not sure what they currently do though.
You explained what layout is, but how's it different from Tiling?
Tiling and layout both impact memory arrangement, so they overlap in terms of what they are trying to express.
The semantic difference is that image tiling is fixed at image creation time, whereas image layout can be changed dynamically post-creation.
The physical memory arrangement for tiled and optimal layouts is entirely implementation-defined, so the actual physical difference is not specified. In many cases the answer is "nothing", in others the answer is "compression", but anything is possible ...