I automate deployments whenever possible to follow the DevOps principle of continuous delivery, and that means I always refresh the dictionary and security caches using API calls against the database. For any new deployment process, I always develop in a DEV environment and play out the deployment script separately in QA, and for really big stuff, I’ll go the full DEV→ TEST→ QA.  This helps eliminate the familiar conversation:

“The new feature is broken in PROD. I thought it worked in QA?”

“Oh, sorry, I forgot a step.”

So my reasoning here comes down to a people and process issue more than it is technical.

As a side note, refreshing the dictionary cache from the database allows you to provide an argument to only refresh what you want, such as ‘PACKAGES’ or ‘VIEWS’. The GUI doesn’t let you specify these.

For my 2c, I think that for most people running it from inside IFS makes most sense - it is just simpler to execute.

In much early versions I’m not sure I trusted it so much, but for recent versions I’m comfortable with the interface approach for ‘everyday’ work.

Like you I’ve also not seen any differences between doing it from the GUI or doing it programmatically in the DB.  Since most changes we make (apart from deployments) are in the interface itself, that seems to be the path of least resistance.

Nick