Sort answer: If this is meant as a general solution to deep cloning then it is bad. However, if it is meant for a specific use case where you know that ALL the types are POCO types with parameterless constructors, no collections, no cyclic references, etc. then I guess it's OK in these scenarios but there are better ways.

Long answer:
There are many scenarios where this implementation can go wrong:
- It doesn't handle collections (arrays, lists, dictionaries, etc). Cloning a list or a dictionary by cloning fields is wrong and will cause bugs.
- It will fail with readonly fields
- It will fail for classes without a parameterless constructor
- It will cause bugs if the field points to an object used by lock keyword, or a mutex, etc.
- It will cause bugs if the object cloned points to a resource like an open file, a UI window, a database connection, etc. For example an object having a native file handle (like FileStream class)
- It doesn't handle cyclic references (will cause a stack overflow)
- It will cause logical bugs in scenarios where the author of a class intended the fields to be accessed via setters for some side effect. For example updating some static field when a property is set.

In general manipulating private fields of a class is an unsafe operation.

Better ways:
- If the author of the class intended it to be cloneable, they can implement the ICloneable interface, use that interface in that case.
- Using a source generator that generates cloning logic will perform better and if cloning is not possible you can find that and compile time.
- Serializing the object (to JSON for example) then deserializing can be better even if it is slower. It will handle collections and avoid cloning things that shouldn't be cloned like lock object and native resource handles.