Well - being that this is OpenSource .... and the core is written in JAVA.... you *could* add your own functions via a JNI Interface. There is no reason you could not add an interface to support your own functions - assuming you have the licenses to build the Pro/TOOLKIT / ObjectToolkit libraries and distribute them internally.
Our primary reason for using JLINK started years ago...
- everyone had it - typically installed by default with Pro/E / Wildfire / CREO.
- asynchronous communication enabled us to "not require Corporate IT department involvement to install/configure software" <--- HUGE!
- Java was less code to get down the road than Pro/TOOLKIT (back when we started writing our core interfaces)
- Java was pretty much already installed everywhere also. (but today -- our commercial apps like Nitro-CELL include JAVA with the distribution to remove machine localization and version problems that we came across over the years)
- We could do pretty much everything we needed to do, and our customers needed to do, with JLINK for ProE / Wildfire / CREO Automation Purposes... Our approach and philosophy was waaaay different than the typical Pro/TOOLIT developer's approach to automation that we have seen over the years. Most of our automation processes have focused on the "flow" of data and regeneration ... not creating everything from scratch like a user does.. So JLINK satisfied our goals in this regard 10+ years ago -- just as it does today.
I think the biggest thing we have learned, and tried to teach our customers over the years... Pro/E / Wildfire / CREO have ALL gotten better and better and better as a modeling and documentation tool. IF you are planning for change, it will respond and execute properly -- IF you have planned ahead ... specifically the workflow of what data goes in, how and when to produce the desired results. So we encourage our customers to think about the flow of data and execution -- INSTEAD of what a "user does" to get to the same result. Specifically - TRUST CREO will do what you tell it to... When you step back and really look at it that way - things get easier, and are more repeatable and useful. There are going to be barriers you hit, but that is when you fallback to "how does a user fix that issue?"
--- START EXAMPLE ---
Years ago I was talking to some corp Pro/TOOLKIT developers about our interfaces and how we do things. One example that came up was to "update all the parameters in every part of a large assembly"....
I asked them "how would you do this?' -- the answers mostly came back -- "open the assembly, walk the tree, look for a part, process each part you find during the walk, keep track of each part processed and skip them if they come up again."
My response confounded them... "NO! Open the assembly, get all the parts from memory, process each part... regenerate the assembly. DONE!"
They sat there dumbfounded for a sec. Until the lightbulb went off and they realized that they were looking too close at the problem! They got caught up in the complexity of the Assembly structure on the screen and forgot that all the unique parts were just sitting in memory no need to walk an assembly structure to get to any of them... just get "what is in memory" and process those!
--- END EXAMPLE ---
The above example highlights the approach we fundamentally use for Automation of CREO. Sometimes the simplest, fastest and most efficient way to do something is NOT to look at the screen. 
Hope this is all clear. Thanks for inspiring a detailed response.
