There are some differences between the keys of AES and 3DES. However I do think that your colleagues are more interested in the security of the primitive itself. The AES block cipher is rather more secure than triple DES.
If a 128 bit triple DES key is created the amount of effective key bits - the bits actually used in the protocol - is 112 bits. This is because there is one bit (the least significant one) in each byte assigned to create odd parity. This way the correctness of the key can be validated with certainty if a bit is flipped by mistake. Some implementations require these parity bits to be set correctly, other implementations simply ignore the parity bits.
A 128 bit triple DES key $K$ actually contains 2 keys, key $A$ and key $B$. Both keys are 64 bit (56 bit effective). These keys are used in single DES mode: $E_K(m) = E_A(D_B(E_A, mesg)))$. However because of a meet-in-the-middle attack on this scheme the security margin of this scheme with two DES keys is only about 83 bits or so. When three keys are used (as in $E_K(m) = E_C(D_B(E_A, mesg)))$ the security margin is about 112 bits.
AES-128 on the other hand uses all 128 bits of the key, and provides a security margin that is almost but not quite the same as the key size (over 127 bits). Furthermore the AES block cipher is faster, has less quirks (such as parity bits, weak keys) and has a larger block size - which is required for some (authenticated) modes of operation.
Two key triple DES has effectively been deprecated by NIST, and should only be used for legacy applications. Three key triple DES is still acceptable according to NIST SP800-131A, although it is still strongly recommended to choose AES instead.
As for your last question, yes, usually it is possible to use a "raw" 128 bit key for either 3DES ABA (see above) or AES. However in general it is not advisable to use the same key for different algorithms or purposes. It depends on the implementation if parity is checked for DES keys.
Also note that keys may not just be represented by a raw binary encoding. In a PKCS#11 token for instance (HSM or smart card, etc.) the key contains the algorithm name, a algorithm dependend KCV etc. In those circumstances it is not possible to just mix keys and algorithms.