In the scenario I'm describing nothing is ever written to disk. The uploaded image data is streamed into memory directly from the socket and is processed in situ, when an exception occurs the stack unwinds and deallocates the memory storing the image data.
Writing extra code to delete a file in a catch block doesn't seem like something someone trying to account for failure scenarios would do, it's much more likely that the data was living in memory and no thought was put into failure scenarios in that part of the code.
But it is incredibly unlikely that web uploads are piped directly into custom software rather than just being written as files which are processed later. That would be an extreme amount of extra work for no benefit at all.
Tomcat gives you a http request object where you can just grab the input stream object and pass it to pretty much every library that processes files because opening a file just gives you a fileinputstream so adding general support for inputstreams is much easier than actually adding support that only works on files.
It's not at all unlikely, this is the default behavior for various setups, e.g. nodejs with express which is primarily a streams based system where you'd have to do extra work to write to disk.
Writing extra code to delete a file in a catch block doesn't seem like something someone trying to account for failure scenarios would do, it's much more likely that the data was living in memory and no thought was put into failure scenarios in that part of the code.