Philippe: did you consider the down-sides to these changes? It's fine if you want to make these changes locally, but consider undesirable behavior if they were the default:
1. If internalBegin is not synchronized the timeout for a transaction would bleed over into other transactions; unfortunately this is a major weakness with the JTA API: you can only change timeout for the entire transaction manager, you can't set it for a single transaction.
2. If the debug stack is not maintained it makes it harder to track down transaction and various database-related issues, even in production. If you haven't found it to be useful, then again, it's fine to change locally but it is valuable information to have when tracking down bad code or certain lower-level problems. Also, have you done performance measurements with and without to see how much of a change there is?
About the synchronization problem, that is a significant performance issue that I have seen while working with clients. However, the real cause of the problem is higher up because by default all screens are run within a transaction, and really it's pretty rare that a screen needs to be run in a transaction, so that is where a change should be made.
Either way, performance "improvements" without metrics and tracking down the main cause of problems is likely to produce as many problems as it solves.
Based on that, I'd say these changes should NOT be committed.