*결론은 큰 차이가 없으나, OO 개념에서는 LIK만 지원된다.
예를 들어 ALV에서 인터널 테이블을 TYPE으로 선언하면
필드 카탈로그가 작동하지 않는다.

For all practical purposes there are the same. The only additional advantage with types is that you can define your own types(including complex ones) in the data dictionary and reuse them accross various programs.

But within a program if two variables are defined one using LIKE and another using TYPE, both referring to the same field, then there is no difference.

If I include a type pool within a program, then I can define my variables only using TYPE to refer to any type defined in that pool. I cannot use LIKE in this scenario. Also, if I want to use native types like C, N, etc, I cannot use LIKE there either. I can use LIKE ABC only if ABC is in the database or if ABC is defined previously in the same program.

I can use TYPE ABC, if ABC is defined in database as a TYPE and included in the program with the statement TYPE-POOLS. I can use it, if it is the native types. I can use it, if it is already defined in the dictionary as a structure/table or structure/table field, or even if it is defined as a data element or a domain. So I can declare a variable V_BUKRS TYPE BUKRS, but I cannot define a variable V_BUKRS LIKE BUKRS.

But if I intend to use V_BUKRS to store company code, I will prefer to declare it as V_BUKRS LIKE T001-BUKRS, only because if tomorrow for some reason, the definition of T001-BUKRS changes to a data element for example, BUKRS_N(say DEC 4) instead of the data element BUKRS(CHAR 4) that it refers to now, I don't have to change my programs because I am referring to the table field and inhereting its properties. Whereas, had I declared my V_BUKRS TYPE BUKRS and the table now changed to BUKRS_N, I will be forced to change my program as there will be a type incompatability.