The main advantage of Pascal is super fast compilation, but C++ modules should close that gap once they make it into the standard.
This really means it doesn’t permit variably-sized arrays without a hassle on pure language level, so you can’t fall from a bike because it’s wheels are buried in the basement. Manually-specialized Containers like TStringList still use GetMem() and align a pointer to an “infinite” array to that block, shy trick pretending to be safe until reinvented by mere mortal. Iirc, you had to destroy ^properties in destructor by hand too.
Pascal only seemed easier because of three things: a) explicit pointers are hard, b) strings have explicit length of 8 or 16 or 32 bit, and that was also a mess, especially in C interfacing, where PChar worked as intended only half of the time, c) no CS-hard tasks were solved in Pascal by RAD-programmers.
Don’t let your fond memories trick you too much. You can get the same/better behavior and speed by using glib, apr, objc, etc and not using pure C arrays at all.
Quite a few parallel programming research papers were done in Concurrent Pascal during the 70s.
Besides UCSD Pascal, there were a few other OS CS research done in Pascal variants.
Variable legth arrays were available.
C string manipulation is a joke as well, given that in 2017 still doesn't have a way to handle unicode in spite of wchar_t.
The whole point of unsafe code being hard to reach for, is to force people to think instead of producing yet another artifact to hang on the CVE list.
Finally, if we are no longer discussing pure C then Pascal also has libraries and extensions, nothing special about C here.
In any case, there is no need for C when we have C++, other than keeping UNIX kernel devs happy, and legacy code.