PLSQL code for form regions is supposed to work the same way as it does for page processes: so you can (and should) use page items. Interactive Grid is different, since there are no page items there - column names are the only available reference.
Column Names are also available for the Form region (as you have noticed). In PLSQL code, column name binds are available for all values which APEX uses to execute the actual DML operation. For a delete, only the primary key is needed, so APEX binds only the primary key item(s).
May I ask why you need the :ENAME / :P8_ENAME value for a DELETE operation? One could load the form, change the ENAME value to e.g. JOHNDOE and click DELETE. Your PLSQL code would process JOHNDOE (which is meaningless, because it was never stored in the table). If you want to get a hold on the old column value of a table row for a DELETE operation, you should work with the RETURNING clause ...
DELETE FROM EMP WHERE EMPNO = 7839 RETURNING ENAME INTO l_ename;
This would retrieve the ENAME value which was actually stored in the table before the DELETE operation.
I hope this helps
The ENAME was just a test I created, but in my actual situation I have a complex view involving multiple tables and the column I need is a user input like "reason for deleting". The user can delete in two modes, one individual record (which I use the form ARP) and a multi delete feature (which I use the IG). My ARP code is all stored in packages and I tend to use the v() function to grab data rather than passing parameters via bind variable. I was hoping to use the column name (rather than the page item name) so my package would work regards what page or process called it.
so yes, in this case you would need to use item names ...