Your interpretation of line 2 is incorrect.
ldr r10, [r14 , #0x555]
This instruction adds 0x555 and the contents of r14 (0x1234), resulting in the value 0x1789 (which is not stored back in r14, btw.). This value is then used an an address to load a word (32 bits) from memory at that address (note that this is an unaligned access which some ARM processors might not support). Thus, after the execution of line 2, r10 contains the value that was loaded from memory address 0x1789 (which is not given in your example).
Line 4, then, takes the value in r10, shifts this by 15 bits to the left (the lsl #15 part of the instruction - this is essentially a free operation on ARM since the ALU includes a barrel shifter in front of the second ALU input) and adds this shifted value to the value in r15 (0x6666), storing the result back into r10.
You might want to learn more about the details of ARM addressing modes, e.g. from this slide set.
Note that using r14 in ARM code is quite unusual, since this register is commonly used as the link register (LR) which stores the return address for subroutine calls.
Using r15 is even more problematic, since this register is used as the program counter (I will assume that your original disassembly uses different registers). If your code really uses r15, the instruction in line 3
mov.w r15, #0x6666
seems to cause the processor to continue executing at address 0x6666 (effectively, a jump), so line 4 will not get executed at all.
However, this would cause an exception here, since either (1) you are running in ARM more and 32-bit ARM instructions have to adhere to a four byte alignment (0x6666 is not divisible by 4) or (2) you are running THUMB code. This allows for two byte alignment, so 0x6666 would be a valid target address. Alas, ARM CPUs supporting THUMB use the convention of requiring bit 0 in the target address to be set to indicate THUMB code at a target address, which is not set here. So in any case, line 3 would result in an exception.