Unless you use some handy client tool like TOAD, that is, where you can easily see the constraint text in the "Constraints" tab of the right-hand pane in the schema browser; then you can administer them from there and pretty much disregard the system-assigned constraint names in the left-most column... But it's there nonetheless, and AFAICS it has to be what TOAD uses, "behind the scene"(*), to do the same thing you used to do manually.
Also, if you only ever change your tables by dropping and re-creating them, then you can of course just alter the (anonymous) table-creation script you've saved somewhere and re-run it. This is where the copy-alter-restore technique comes in handy: "CREATE TABLE MY_TABLE_TEMP AS SELECT * FROM MY_TABLE; <<run your table-creation script (drop MY_TABLE first, if that isn't in the script)>> INSERT INTO MY_TABLE (SELECT * FROM MY_TABLE_TEMP); DROP TABLE MY_TABLE_TEMP;". That's actually how I often do it on development boxes, when I don't have TOAD available; unless the structure has changed too much in terms of added / dropped / renamed columns, that is... But for stuff like check constraints, it works fine.
But, apart from these "special cases" / personal technique preferences / workarounds, the general rule of thumb is, YES, you *should* name everything, including constraints.
HTH!