If I can set the property directly via person.name = "John" they why
  to use a Set Value for key name = "John" indirectly
Please read “What is the point of key-value coding?”
Apple doc says
  key-value coding compliant can participate in a wide range of Cocoa
  technologies like Core Data. Why it's used and not in other frameworks
It's used where appropriate. It's used where it is helpful and the performance is acceptable. If it's not useful, or if its performance is too low, it's not used.
It is used during runtime or dynamic to set value. How it is?
Key-Value Coding uses the Objective-C runtime to look up getter and setter methods, and to find the types and locations of instance variables if the setters don't exist. See Friday Q&A 2013-02-08: Let's Build Key-Value Coding for a detailed analysis.
Apple documentation briefly describes the implementation of Key-Value Observing here. It's short enough to quote entirely:
Automatic key-value observing is implemented using a technique called
  isa-swizzling.
The isa pointer, as the name suggests, points to the object's class
  which maintains a dispatch table. This dispatch table essentially
  contains pointers to the methods the class implements, among other
  data.
When an observer is registered for an attribute of an object the isa
  pointer of the observed object is modified, pointing to an
  intermediate class rather than at the true class. As a result the
  value of the isa pointer does not necessarily reflect the actual class
  of the instance.
You should never rely on the isa pointer to determine class
  membership. Instead, you should use the class method to determine the
  class of an object instance.
Mike Ash gave a more detailed analysis in Friday Q&A 2009-01-23.
Is it
  TypeSafe and how?
It's not particularly type safe. For example, it doesn't stop you from storing a UIView in a property that's declared as NSString, or vice versa.
Its an Objective - C feature then why still used in
  Swift 4 with latest improvements with ./Type.property access and set
It's still used because most of Apple's SDK is still implemented in Objective-C, and because it lets you do things that you cannot do in Swift without much more “boilerplate” (manual, repetitive functions). The trade-off is that Objective-C is lower performance. In many, many cases, the lower performance of Objective-C (compared to Swift) is not a significant problem, and the increased dynamism is very helpful.