libLAS can indeed be used commercially. So can Martin Isenburg's LASlib, which is LGPL, and speaking as the author of libLAS, faster and more completely supported than libLAS. Both are indeed C++ libraries, however, and there isn't too much in the ASPRS LAS space for native .NET.
I'm also the primary author of PDAL, and PDAL can also read ASPRS LAS data, but again, this is C++, not .NET. PDAL is my current project now, and I actively support it in contrast to libLAS, which is in more of a maintenance mode. PDAL's license is also BSD like libLAS', and commercial licensing is not an issue. PDAL can be thought of exactly as its raster data cousin, GDAL, and unlike PCL, it focuses on data format translation and access rather than point cloud exploitation activities. These libraries can be definitely used together, but they are compliments of each other rather than competing visions of LiDAR/point cloud data processing.
Another option you might consider is using https://github.com/grantbrown/laspy which is a pure-python implementation of ASPRS LAS support. You could use this with the .NET port of IronPython and NumPy to get native LAS support on the CLR, though again, it would not be C# per se.
FUSION LiDAR Toolkit has clipping capabilities (PolyClipData tool) and unlike LASTools, its usage is unrestricted. However, despite the fact that some SVN repository on SourceForge exists, the source code published is incomplete and very old. If you can proceed without knowing the code and just use the compiled binary, then FUSION should be fine for this task.
Best Answer
Not sure of a complete package I'm afraid. Given that it is very specialised you might struggle to find one unfortunately.
However, if you are keen (or know someone that is) you could always try building one...
From the Velodyne HDL 32E user manual Appendix B:
In theory this means that to capture data all you need is software listening and capturing data on Ports 2368 and 8308. One solution if you know Python would be Twisted - see this documentation on listening on UDP ports.
Then you could go on with modification of the script that you'd already seen on binarymillenium - and in the Velodyne manual is a diagram that describes the content of the UDP packet which you could hopefully use. From there how you use the data is up to you.
Sorry I can't give you a packaged solution, but hopefully this helps!