This article doesn't intend in suggesting a move from AFP to CIFS, it only cautions the users about the possible file corruption with AFP when the ZID > 4.2 billion and ways to avoid that corruption. Please note limiting a volume to ZID32 doesn't stop the file IOs untill ZID Ids reach the upper limit of 4.2 billion, if any ZID32 set volume reaches 4.2 billion mark, we can always rezid that volume to release unused ZIDs and resume the file IOs on that volume.
However, you are right in proposing the roadmap to move from AFP to CIFS for longer term benefits.The Apple is focusing more on improving SMB stack on it MAC clients and less focused on it's own AFP protocol. In last 3 years the Apple has made SMB as its default protocol to connect to network shares on it's MAC clients and also intends in improvising SMB performance in MAC clients. AFP is still supported by both OES and Apple but the roadmap is set for SMB to be more prominent on MAC clients.
But the query related to resource forks is also very much valid, and so it was also addressed sometime back on OES servers. The novell-cifs is capable of supporting "Alternate data streams" (ADS)which is an equivalent to resource forks.And to migrate resource forks created with AFP to CIFS, there is an "migafp2cifs" cli utility available on OES servers.
So with combination of "Alternate data streams" (check novcifs man page) and "migafp2cifs" cli , the migration of resource forks to ADS of SMB/CIFS is already tested and very well supported to help in the migration from AFP to CIFS in OES deployments.