If foreign keys/cascade deletes are bad, why use a database-server with that feature? I noticed wordpress/rails etc do not use foreign keys constraint or cascade deletes features from database. Instead they handle this in PHP/Ruby/scripting level!

I have read this and this. Most arguments against foreign keys constraint talks about performance, multithreading, locking, scalability, etc. 

Assuming arguments against foreign keys are valid, my question are:


If foreign keys are bad, why WordPress/Rails/etc uses a sql-server which supports foreign keys? Will they benefit going away from MySQL to a NoSQL kind of server?
On other hand, can applications coded in a way to make use of foreign keys feature without running into issues?
Is noSQL/redis better if we are using database only for storage and managing "relations" at application/script layer?
Lets start with your first link. It says clearly:


  Working on large databases with referential integrity just does not perform well.


And that is right. Just you likely have no clue that "large database" is terabyte size with billions of rows in a table. A simple select may cascade into hundreds of millions of related elements to be deleted, and then you have a performance problem.

This is a non-issue for regular small databases such as a wordpress log or most CMS - it turns into a problem if you do something like facebook, or handle financial simulation data. I regularly deal with multi billion row tables and deletes that work in stored procedures outside of transactions in batches of x - because the end delete may easily clean up some hundred million rows.


  Will they benefit going away from MySQL to a NoSQL kind of server?


Hardly. They are useful when a professional uses them as appropriate.


  On other hand, can applications coded in a way to make use of foreign keys feature without 
  running into issues?


Yes.


  Is noSQL/redis better if we are using database only for storage and managing "relations" 
  at application/script layer?


I once did a application review for a technology upgrade in a bank that uses no referential integrity (to get the performance up). Loading the data into SQL Server (which was supposed to replace their aging Adabas installation) it failed with integrity constraint violations. Happens 40% of the historical records were invalid because some * had deleted lookup table values not in use any more (such as old customer classification codes, which got replaced for all active customers, just not the old ones). No referential integrity warning ever came up. The result was some fired people and a problem stuck in workaround and a partially useless data warehouse build on top.

So much for managing relations at application / script layer. Errors WILL happen. Data is valuable, applications change.

Most people complaining about SQL level features would be more advised to read a book about them, and try to understand them, instead of complaining. Sadly a lot of the advice on the internet is written by people that refuse to read even documentation. Always be careful with that. Most advice to NoSql is based strongly on ignorance.