Generally it is considered bad practice. It makes your code non-reusable too as if I had something like this:
Do some stuff;
Then I can't do this:
because y will only ever rollback to post x. So you end up with an inconsistent state. And your code is non-restartable. The developers guide [https://docs.oracle.com/cd/E18727_01/doc.121/e12897.pdf ] is a bit vague on it (it doesn't prohibit commits in the code but says it must be the last thing you do).
There are some situations where a commit is unavoidable however - for example if you are submitting a concurrent request from within your code and need to wait for it; because the concurrent managers won't pick it up until uncommitted. This can be resolved with an autonomous transaction if need be.
Ultimately though - avoid it where possible - as you already said, let the application do the commit.
Thanks! I also asked this in another community (sql - Advisable to put a Commit in an Oracle EBS Concurrent Program? - Stack Overflow) and they agree with the above mentioned reasons. Glad to know i'm doing it right! The next problem is how do i tell the other developers that its bad practice.
I'd ask them to justify their reasons for doing so. I'd imagine they will say something like "it reduces rollback", in which case there are still plenty of arguments against that, especially when this is done inside a loop.
When I see commits mid-way through programs it usually says to me that the developer doesn't really know what they're doing. As I said, sometimes it's unavoidable, but when those (rare) situations arise there needs to be a lot of thought and effort put into the process design and orchestration.