Is it bad idea to create foreign keys on the tables in a different schemas in the same database for big applications?

Schemas are nice to isolate tables from logical subsystems. Foreign keys guarantee data integrity. These are orthogonal concepts - as obviously data integrity between subsystems is also a must have. Accounting and Shipping and possibly Central Customer Data do not live in silos where a customer can get deleted while being used in accounting.

This is how I do it on SQL Server (although, again, our definition of schema is IIRC a LITTLE different from the Oracle definition).

As such, I think the requirement of the DBA is a sign of incompetence. T

While demanding the destruction of foreign key constraints without detailed reasoning is foolish, it makes sense to keep the outside references under control. What if the schemas you are referencing are named differently on your new server?

In Oracle you resolve this problem by creating SYNONYMS for objects that are outside of the current schema.

If you have the need (space/security/whatever) to move any schema to a different database, you won't be able to handle the references any longer. That is probably the main reason to request killing the references.