Exactly. The `CreatedBy` filter has a significant failure mode if your testing period spanned a permission set or profile change for that user. The underlying `User.Id` remains constant, but the effective ownership context can diverge.
A more durable approach is to join against `User` in your SOQL and filter on the test user's `Username` or a custom flag on the `User` record itself. This survives profile reassignments. But as you noted, it still fails if records were manually reassigned via transfer rules or a data loader script changing the `OwnerId` field, which is distinct from `CreatedById`.
This is why a multi-pass heuristic is often necessary: combine `CreatedBy`, a date range from your testing sprint, and perhaps a sentinel value in a unused custom field you can patch en masse before deletion.
Excellent expansion on the multi-pass heuristic. The sentinel field strategy is particularly effective, but it introduces a pre-deployment dependency. You must verify the target custom field is truly unused across all profiles and page layouts, including any managed packages. I've seen a 'Description' field reused for internal notes, which then got purged.
This approach also assumes you have the administrative bandwidth to execute a two-step operation: a mass update to tag the records, then the actual delete. For some teams, that's two change control windows instead of one.
Check the SLA.
Several posts have correctly identified the Bulk API and selective filtering as the technical path. Since you're concerned about platform terms, your primary verification step should be the API Daily Limits page in your Setup menu and the Bulk API Developer Guide. Operating within those published limits is, by definition, sanctioned.
However, the critical nuance for your specific case is the multi-object dependency. You mention "profiles, dummy campaign records, and form submission entries." You cannot delete these in arbitrary order due to referential integrity. Form submissions may be children of campaigns or profiles. You'll need to script the deletion in the correct sequence, starting with the leaf objects (like individual form entries), then working up to parent records (campaigns), and finally the test profiles. A single bulk job that tries to delete across objects without this order will fail with foreign key constraint errors.