No, InBatch is not an HMI. It has a GUI, but not configurable like SCADA/HMI. It's not programmed like a PLC, the PLC and InBatch have to align. So the PLC needs code, InBatch needs to communicate with that code via tags (similar to SCADA). InBatch and the PLC must align with the processes or 'phases' that are to be controlled. If a phase called "Liquid Addition" exists in the PLC, InBatch must have a phase configured to control the PLC phase. InBatch must command the PLC phase to Start/Stop/Hold/Abort. It must read the state of the PLC phase to understand if the phase is running/holding/aborting/complete. InBatch must send the recipe setpoints for each phase to the corresponding phase in the PLC.
InBatch is the Foreman and the PLC is the worker.
InBatch tells a PLC what processes to run, what parameters to run them against and when to run them. It also collects a bunch of data, handles PROCEDURAL recipes, allowing the end user, at runtime to create recipes that change not only setpoints, but the actual order of the PROCESS. The end user can build the recipe any way they wish (within physical equipment constraints). Can manage the raw materials, has change management features and more...
You can't accomplish all of this in a traditional SCADA system unless you're building something completely custom. I've come pretty close to doing so, but it's very difficult to allow users at runtime to create complex recipe procedures with just a SCADA/HMI and a PLC. And do so in a manner that is fluid and easy to follow (even if InBatch itself feels dated).
InBatch has it's quirks, and unless you need to allow users to manage procedural recipes at runtime, you may not require it. I'm a big fan of using batch style programming for any process, but doesn't mean I have to use InBatch. I can use SCADA/PLC to control much of the logic, however I can really only get away with that on a fixed, linear process. Or one with very basic procedural options.
For example, if I have a batch system that was mechanically designed to only allow the user to create 1 type of cookie, no need for a system like InBatch. The process sequence to make a single type of cookie is pretty simple and can be accomplished with 'fixed' process logic. If I have a batch system that was mechanically designed to allow the user to create ANY type of cookie they can imagine (multiple automatic recipe ingredients available, limitless options with manual additions, have heating/cooling, mixing equipment). Well, you can't possibly account for all the combinations they could come up with unless you build a very complex one-off system using SCADA. InBatch puts the process sequence into the hands of the recipe creator.
Batch systems like InBatch align with ISA-88, and using it in conjunction with PLC ISA-88 tools such as Phase Manager in a ControlLogix PAC, well you have a very good system.
Ultimately, InBatch can be overkill depending on your actual process and what the mechanical equipment is actually capable of. Sometimes you need procedural recipe control and it's great at that.