No. [1] contains a complete Unix C build environment (tools, headers, libraries) that’s used when you build command line tools or otherwise make use of the Unix execution environment from within Xcode. There are different ones depending on the platform/SDK, but they are encapsulated within Xcode so that they don’t get mixed up with tools etc that are built outside the Xcode environment, since /usr can be highly customized under other build systems.

[2] is (I think) the same kind of thing, but left over from an earlier Xcode strategy where there was a separate Xcode build environment, but only one. This didn’t work so well if different versions of Xcode were installed simultaneously. (Remember when that was a thing?) I don’t have those files, because (I think) my Mac isn’t old enough.

[3] is a standard location for user-provided or user-customized build tools, so it may contain things you’ve downloaded or modified.

The general idea is that anything you do from or within Xcode is a standardized execution environment that you can’t mess up by other Unix-compatible development activities. /usr is yours to mess up without having to worry it will cause Xcode to fall in a crashing heap.