I'd strongly recommend using mono for the foreseeable future rather than .NET Core. Mono will not go anywhere, it's been around forever now, and is stable and has very mature tooling. And it is the backbone of plenty of things at MS (Xamarin, Android and IOs compatibility etc...) so there is a permanent commitment to it. It is like the .NET framework at this point, it can't go away.
In terms of memory footprint, mono may be less optimized than .NET Core out of the box, but let us remember that the fundamentals of the VM are the same because they both implement the same specification : if you do not touch an AppDomain, it does not get loaded in memory. And if the VM is still too heavy for you, if you are truly at the scale where every megabyte matters (unlikely unless you are operating at a huge scale, of have aggressive hardware constraints), it likely won't be a big deal for you to tweak mono's compiler options to trim it and optimize it as much as you need.
The memory footprint of the VM of an headless web application on mono is about 60MB to 200MB, most applications would use about 100MB (putting aside load and the specific performance profile and resource usage efficiency of the application). This is negligible most of the time, unless you plan to run on an embedded device having 256mb of ram installed, in which case you'll still be able to play with mono's compiler options. And I am not the type of person considering that running an electron-based text editor using 2GB of RAM is always reasonable.
I bet .NET Core has been optimized for web scenarios to take the number closer to the one of a LAMP stack (even though this is comparing apples to oranges, since .NET/Mono give more isolation and features to every application - you can import DLLs, and do all sort of things in a secure context, so this necessary involves resource usage duplication where on a LAMP stack everything uses the same PHP instance. This is without even mentioning the sandboxing that .NET provides you - for example I'd never expose my filesystem straight to the web - I'm always shocked to see how much of a direct access to the file system PHP apps use and the tweakings with .htaccess files, scary...).
LAMP can run multiple websites by using well under 100MB of memory largely thanks to the fact that everything uses the same PHP instance and lazy execution. But you pay the price at execution time with much slower execution. But if you are hosting 1000 websites and 99% of them get less than 1000 hits per day, then these maths are arguably very advantageous. The right tool for the right job.
For if you are the marketing department of a company having 3000 websites (blogs, review websites, and all sort of content marketing schemes) to promote a range of specific products using an in-house methodology, then if you are sophisticated, these 3000 websites will likely be powered by a single application, having an integrated dashboard for content editors, and a transparent engine adding styling and graphics assets, and content modules, based on the entity being served (every website would be represented as a well-thought-out entity in your domain model). Then you would for example put a reverse proxy in front of your application to transparently map "marketingdomain1.com" to your backend "
http://localhost:<port-to-your-app>/marketing-schemes/entity-name-for-domain-1/" and you have your 3000 websites powered by a single application using 60-200MB of RAM memory.
And the maths work here too. And the thing is, in addition to the huge security benefits coming for free, and to the huge performance benefits at execution time, .NET/Mono and their family of languages (csharp, fsharp etc...) make it very convenient to create and maintain such complex domain models. The experience of creating a complex, yet scalable and maintainable domain model in .NET and seamlessly integrating it with the infrastructure code, while having access to a broad range of expressive languages (csharp, fsharp, but much more), and a wealth of open-source packages for your infrastructure, this experience is quite honestly seamless. Once you have experienced that, you can't fiddle with Python and PHP if you are serious about your business. And I am not talking about Microsoft toolings (which we do not use anyway), I am talking about core concepts and the core features of the languages, and of the ecosystem and of the way everything plays together to foster productivity, quality and shareholder value in an optimal way.
So honestly it really depends of what you are doing, and whether or not you know what you are doing... And to be honest, most .NET shops wouldn't be able to pull out the technological scheme I have described. They need the click-click-click hand holding of Microsoft's tools to ship anything. And I am just talking about infrastructure code here, I am not even talking about the fact that very few teams even know what a domain model is... they know about POCOs.... and glue.... and spaghetti.... and mapping and ETL-ing stuff all over the place.
So it really comes down to what you are doing, and whether or not you know what you are doing. And what I am saying is that in many - if not most situations - if you are a company only deploying your own products, ECMA 335 is quite a huge baby to throw with the water... You're missing on a lot of value if you dismiss it or do not know about it (which most people do, especially in the UNIX community - but for legitimate historical reasons, but times have changed), and you're probably paying a premium without even realizing it, as you'll have to constantly re-implement here and there many complex and expensive stuff coming for free with ECMA 335 (in addition to introducing codebase complexity, less expressive programming languages etc...).
And once all of this is said.... I just saw a one-year old question on stackoverflow of someone saying that their small .NET Core application (20 pages or so, this was actually a headless JSON-API....) was using 350MB of RAM.... So bottom line is, honestly, nowadays there is not even a practical need for .NET Core if you know what you are doing.
Old is not always true forever. Change is not always meaningful or positive, but sometimes it is. And new is not always better. For those of us able to take advantage on Mono on Unix, .NET Core is a solution to a problem faced by Microsoft more than it is a solution for us, since there is no actual need in this area. However, we indirectly benefit since they significantly scaled their investment in open-source because of this program. For example, they multiplied the headcount of developers working on Mono while keeping everything open-source, they even open-sourced the proprietary division that allowed Mono to make money. They also open-sourced the .NET framework, MSBuild, all their compilers, and all sorts of things, so the Mono team has been able to do things such as swapping less performant code for code developed by the 6-figure-salary full-time PhDs paid by Microsoft where it made sense.
