Yes, in technical terms of how the certificate are constructed and signed, client and server certificates are very similar. They're both just public key, some arbitrary metadata, and a CA signature, and they're constructed pretty much the same way. The only difference between server and client certificate is basically just what metadata is attached to the certificate and how those metadata are validated against the entity.
In theory, if you disable the certificate validation and usage constraints checking in your TLS library stack or if the certificate doesn't specify usage constraints, you can actually use either client certificates as server certificate and vice versa. The cryptography doesn't actually distinguish between client and server certificates, it's only the validations done by the applications that cares about usage constraints and if you control both the client and server, you're free to specify whatever validations you want to enforce for a particular connection.
With server certificate, the certificate metadata specifies the DNS name that the certificate is valid for in the SAN field, and the certificate is validated against the domain name of the server the the TCP stack is connecting with.
With client certificate, the certificate contains the user attributes that the CA had validated. And the server verifies these attributes against its authentication requirements. You can for example add an attribute specifying that the holder of the certificate has blue hair colour, and your server may only allow connections if the client has green hair.
Note that for both server and client certificates, you don't necessarily have to use a public root CA, but because of the way certificates are used, it's much more common for client certificate to use private root CA than with server certificates.
When you use private root, you can define your own certification practice statement (CPS) which allows you to specify your own authentication requirements and any custom attributes that are required to be included in the certificates issued by the private root. This is a level of control that you won't have with public root client CA, which usually just provides simple identification of email address against a person's name because most publiclt rooted client CA are used for email cryptography, not IoT device identification. If you give your IoT devices each their own DNS names, then you may be able to use server certificates with publicly rooted CA as a client certificate, but this would be somewhat of an unusual arrangement.
Note that some CA that sells server certificates against public root CA also provide CA service for private root management. This can be an option to use if you want a professionally managed private root CA but don't want to build your own CA infrastructure from scratch.