Bit-aligned instructions are a really horrible idea if you ever want to make a CPU implementing that instruction set actually fast. When you want to decode multiple instructions in parallel, having more possible locations for the beginning of the next instruction adds a lot of latency and power on a very critical path. Getting more cache to fit instructions and more bandwidth from it to the cpu is a problem that can be solved by Moore's law, having to put more muxes in front of your decoder isn't, now that Moore's law just buys you more transistors and less power, but not faster transistors.
x86 is now considered to be extremely hard to decode because it's byte-aligned instructions, and basically all modern instruction sets prefer fixed-width instructions. ARM used to tout how space-efficient it's THUMB-2/ARMv7 instruction set was compared to other RISC instruction sets because it had 2 possible instruction lengths (16b and 32b), but now that they got to (had to) reboot the ISA for 64-bit, ARMv8 is fixed-width.
For clarity for those who aren't exactly clear with all this, this only applies when the instruction set is actually compressed somehow - not for stack based machines in general.
x86 is now considered to be extremely hard to decode because it's byte-aligned instructions, and basically all modern instruction sets prefer fixed-width instructions. ARM used to tout how space-efficient it's THUMB-2/ARMv7 instruction set was compared to other RISC instruction sets because it had 2 possible instruction lengths (16b and 32b), but now that they got to (had to) reboot the ISA for 64-bit, ARMv8 is fixed-width.