No, it is not entirely orthogonal. In particular, common combinations will have 16-bit Thumb2 instructions, while less common combinations will have 32-bit Thumb2 instructions. For example, in the ARM, like in most RISC architectures, there is not a dedicated stack register - you simply use one of the general registers along with appropriate post and pre increment and decrement addressing modes. But by convention, and codified in the ABI, one of the registers (r13 on the ARM, IIRC) is always used as the stack pointer. Instructions using r13 for these sorts of addressing modes will be common in the 16-bit Thumb2 encodings, but use of the same modes with other registers probably needs 32-bit Thumb2 encodings. (I haven't confirmed the details of this with the ARM documentation, but the principle is accurate.) The same thing applies to similar shorted encodings on other processors.
Yes. The actual balance between size ratios and speed ratios varies a little depending on the type of code being run, but I a gather that ARM and Thumb2 encodings are typically within a few percent of the same speed, while Thumb2 code size is between 60% and 80%. For bigger cpus, the processing speed exceeds the memory speed by a greater amount - they are likely to gain more overall speed due to Thumb2 than on smaller cpus.
There is also the case that there may be types of code that will be noticeably faster in ARM encoding than Thumb2. On a Cortex-A cpu, including the ARM decoder is a tiny percentage of die size, and can be powered-down when not in use - it is therefore cheap to add if people want to use it. For smaller devices like Cortex-M microcontrollers, the size of an ARM decoder (in addition to Thumb2) would be a much bigger percentage of the die size, and therefore a bigger fraction of the cost.
There is more to this: In Cortex M3 and M4, the hardware uses r13 as stack pointer to save the processor state in exception handling. The register can be mirrored to use separate stacks for thread code and exception (and system) code.