The EVM is always 256 bits big-endian. From the Yellow Paper, Appendix H: "When interpreting 256-bit binary values as integers, the representation is big-endian."
RLP is different from the Contract ABI.
From above RLP wiki, encodings "must be represented in big endian binary form with no leading zeroes."
There are no (other) explicit rules about padding in the EVM and RLP.
Some cases treat strings shorter than 32 bytes (256 bits) as left-justified ascii (packed into the most significant bytes of the word).
As Axic's answer mentions: "The Contract ABI defines different data types each with their own layout. Numbers (int*/uint*) are stored left padded, whereas bytes/string is stored right padded."
Does this mean that the word value of the string '*' is equivalent to: 42 << 148 ?
No. The ASCII value of '*' is 42 (decimal). The word value is 42 (0x2a in hex) and the EVM would handle it as 42 (which is equivalent to left-padding the first 31 bytes with zeros, and the 32nd byte is 0x2a).
... the RLP encoding of the single ASCII character '*' is two bytes
False, the RLP encoding of '*' is 1 byte (0x2a).
Are there important edge cases for security and correctness where the EVM word semantics and RLP encodings don't quite match up?
The EVM is always 256 bits big-endian, so any RLP encodings smaller than 32 bytes that are provided to the EVM, will be treated by the EVM as having leading zeros. The ABI (separate from the EVM) is what has semantics about padding, which are important to match up for security and correctness.