if an attacker has a way to calculate correct checksums, this scenario would work. That being said, I think it is very theoretical. Checksum protection is a fundamental security concept and used in all kinds of web frameworks, not only APEX. I am confident that our implementation is at least as good as that of the others.
However, security can (and very often should) be applied on all layers, not only the front end. For example, one layer below the URL / item checksum protection are the form and tabular form processes of APEX. You can add runtime where clauses that APEX automatically adds when it fetches rows or performs insert/update/delete. They can be used to ensure that DML only applies to records that the user is allowed to see and edit. Further below, you have Fine Grained Access control (also known as VPD), that does something similar directly in the database. It is an enterprise feature, but you can also emulate it to some level with views and triggers if you are on standard edition. The final layer is a sound relational data model, where the correct data types and constraints guard the data integrity. Depending on the complexity of an application, it sometimes makes sense to add a logical view/trigger layer on top of the physical model, where additional security checks are implemented.
We haven't found a way yet of calculating the checksum in this manner, it would be equivalent to pre-computing session identifiers in any other web frameworks.
If there was a vulnerability found in the checksum calculation, it would be reported to Oracle and the framework would be fixed (very quickly i should imagine), and all APEX users would benefit from the fix, this is a very good reason to use the APEX framework for such things.
There is one very limited scenario where an attacker can compute a URL checksum and that is when the developer miss-uses the prepare_url function, and includes an unprotected item too soon in the function (page number for example) and thus can receive the checksum for the values of his or her choice. We have only seen this exploitable once in the many applications we have seen and this should be picked up in a secure code review.