When you say "ABAP development" this can mean
(1) Modifying SAP transactions
or
(2) Building your own transactions
In contrast to (1) or (2), GuiXT changes the SAP UI
without changing SAP code. This is not possible with ABAP development.
With the approach (1), it is hard to guarantee that the
transaction will still behave correctly, e.g. does not update the database with
invalid data. In addition, you need to understand the SAP program logic. With
GuiXT you only need to understand the UI functions, but not the implementaiton
logic of the transaction, and you are sure that no incorrect or unauthorized
database content can occur.
Approach (2), yes, this can be used for relatively
simple transactions. The problem here is that the users might need certain
functions of the SAP transaction (now or later on) that may be hard to implement
in your own coding. You then run into a situation where you can neither
suggest that the users work with the SAP transaction (since it is too
complicated) nor can you implement the additional function in your simplified
transaction.
With GuiXT you stay in the original SAP transaction. If
you delete a menu function, pushbutton or entry field that turns out to be
needed later on, you simply comment out the corresponding "del" statement in
your script.
The system performance
can be better with your own transactions if you succeed in impelementing it
better than the SAP standard transaction. But it could also be worse.
With GuiXT you normally need the same system resources as the original SAP
transaction, but you simplify the UI.