Extending C means you get most of a language for free. This can be good, sometimes, but it causes problems if the goals of your language run counter to what C allows. It's impossible to extend C while still providing memory safety, for instance -- that would involve major changes to idiomatic C code.
C++ and Objective-C both extend C in ways incompatible with C itself. C++ changes the default type of character literals from
char, for example, and completely changes the meaning of
auto. Objective-C eliminates the rule that
[[ must start an attribute -- consider the ubiquitous
[[NSObject alloc] init]. They also both add some keywords that restrict what identifiers are allowed in plain C code, though perhaps that's inevitable with an extension like those.
The vast majority of modern languages provide C interop rather than trying to look exactly like C. This allows changes to the syntax, ranging from removing semicolons to completely reinventing the macro system. Most popular languages still have somewhat C-like syntax, and the C family of programming languages is quite large, but mimicking C exactly is usually a non-goal for modern languages.
A drawback to allowing C interop means you have to support C's idioms, even if you don't encourage them: someone's going to need to call a function that uses pointers eventually, and you need to give them some way to do it. Swift has no shortage of pointer types (and three more), to be used in different situations. Some languages care less than others, though, and some require the glue code to live on the C side instead. Sometimes, giving a language access to pointers means breaking the promises you started with: for example, C#
void* is an exception to "everything is an
object", and Swift's pointers provide a very easy way to violate memory safety.