When comparing MacPorts vs Nix package manager, the Slant community recommends Nix package manager for most people. In the question“What are the best Mac package managers?” Nix package manager is ranked 3rd while MacPorts is ranked 4th. The most important reason people chose Nix package manager is:
Every time your profile changes, you get a new generation of your profile and older generations are kept around, so you can easily (and atomically) revert to older version of your profile.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Provides a consistent experience across OS X versions
MacPorts eschews Apple-supplied libraries and links sources against its own making sure that the experience is the same regardless of what OS X version is used.
Pro Easy to use
Detailed instructions on the homepage are easy to follow. Official GUI app is also available
Pro Generally very up to date
MacPorts generally gets new software soon after it's available. This way users will not have to worry if their software is up to date.
Pro Nice variants system
MacPorts has a variants system that allows customizing builds with author provided options.
Pro Has many more packages than its competitors
As of this writing, 20K packages. 3 to 5x more than other current package managers.
Pro Requires SUDO to install apps
No need to worry if some rogue app will change your binaries or configuration.
Pro Download libraries instead of relying on Apple's caprices
Considering just how often Apple breaks things, any reduplication of of Apple-supplied libraries with the canonical sources is an asset.
Pro Fast
Written in Tcl & C, it's generally significantly faster than the competition. Tcl is also quite readable and comparable to Ruby, so it's also friendly to newcomers.
Pro Supports older Mac operating systems
Homebrew dropped support for old Macs. MacPorts still supports them.
Pro MacPorts is a native application: C + TCL
No need to install Ruby, or any other programming language.
Pro More packages than competition
Pro Apple Silicon Ready
With Apple moving over to its own silicon, macports has been ready for the move to ARM since 2.6.4
Pro Initially started and developed by Apple employees and supported by Apple itself
Reading the story behind MacPorts, it is the only one that was developed by Apple by an Apple employee. In fact it is the same person that was responsible for creating the FreeBSD port system.
Pro Great support for older systems
Pro Most of the available packages work
For example, trying to install Finch using Pkgsrc doesn't work, while installing it using MacPorts works perfectly. Finch isn't even on Homebrew's radar.
Pro It's easy to revert any change in your environment
Every time your profile changes, you get a new generation of your profile and older generations are kept around, so you can easily (and atomically) revert to older version of your profile.
Pro Packages installed with Nix don't overlap with packages installed in /usr/local
Since packages are stored in the /nix directory, it won't overlap with anything you'd install in /usr/local or wherever else.
Pro Can keep around several profiles for you to use
You can have different (probably overlapping) sets of software installed in two or more profiles that will be handled (changed, versioned, upgraded, reverted) independently. All software will be installed in the same /nix/store, so any overlaps between your sets will be physically installed only once.
Pro You always and atomically get an isolated consistent profile
Every time you install, delete or change anything you get a new fresh copy of your user environment (set of symlinks to files in /nix/store) that's stored in the same /nix/store and handled mostly the same way. Your "profile" (symlink to one of environments) is updated after everything else is ready, so you'll never end up in a half-finished state of your system.
Pro Does not require root priviledges
Everything is owned by your user (unless you use more powerful multiuser mode that doesn't require root either).
Pro Uses binary caches (that are provided) so you don't have to build anything locally
Due to its functional nature, it can just download a binary package with the same hash if its available and it'll get the very same package as you'd build locally (to the last bit that is).
Pro Packages don't change after they are built
Nix treats packages like values in a functional language. Since they are built by functions without side effects they never change after they are built.
Pro Very easy to share compiled binaries between machines
You can share packages via HTTP or SSH (push or pull) with just some simple commands.
Pro Easy to install
Requires just one shell script to install, only one directory is created via sudo. This makes for a pretty simple install method that most can grasp.
Pro Many apps
Since it is compatible on Mac and Linux, there are many apps in their repos.
Cons
Con New Packages and Updates take time
Macports isn't the first choice for developers producing new packages or binaries for macOS. Nor is it the fastest in getting updates. But in general, it usually is one of the most up to date and will be updated eventually. Some would see this as a con in comparison to Homebrew.
Con Bad at limiting dependencies
MacPorts has a habit of pulling very specific versions of dependencies for each package. It downloads different version of already existing dependencies even in cases where the existing dependency version would have worked seamlessly.
Con Downloads unneeded libraries duplicating functionality already provided by Apple's libraries
As MacPorts eschews Apple-supplied libraries and links sources against its own a large duplication of functionality across MacPorts and Apple libraries can be found.

Con Requires root permissions (sudo) for installation of packages
A really good security feature, but some see it as a con.
Con Steep learning curve
There are lots of unfamiliar concepts and jargon (e.g. fixpoint, instantiate, realise).
Con Cannot handle filetypes that have different semantics across different versions
While the functional approach that Nix takes is great for sandboxing binary artifacts of packages, it seriously lacks any power in handling configuration files or user data. It's difficult to upgrade and downgrade files where semantics and syntax can change between versions. Especially in Debian/Ubuntu it can cause severe problems where the upgrade process blocks and the user needs to resolve the 3-way merge.
