There's a lot a variables to be resolved before a simple "No" can be given.
Is the table versioned?
Does the table participate in geodatabase topologies, networks, or object behaviors?
Does the layer use SDEBINARY/SDELOB storage? If so, is it in LOAD_ONLY I/O mode?
In general, there are triggers to maintain referential integrity, but any of the above
could preclude the safe use of DELETE. Note that the same problems would exist
if you used the ArcSDE API (SE_stream_delete_from_table is just a wrapper on
a SQL delete), but the I/O mode problem would probably be caught at the API.
- V